The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1994)
DOCUMENT: TCP-IP Distribution List for August 1994 (737 messages, 438655 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1994/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 1994 13:05:09 -0700
From:      warrl@connected.com (Donald Edwards)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast delivery

matt b (mbolce01@kadavu.ae.eds.com) wrote:

: Could anyone provide me some insight as to the proper socket code
: semantics to use to issue a packet with a destination address of
: "255.255.255.255"?  I have already tried setting the socket option
: for SOL_BROADCAST to true, with no luck.  I seem to only be able to
: broadcast to all hosts on a known network (e.g., x.x.x.255), but get
: routing problems with the "255.255.255.255" dest, or a "bad value"
: when I try to force a route out an interface for that broadcast
: destination.  I have a feeling I'm missing something obvious.

One obvious thing is that not every IP address in the world needs to
receive the packet...   

     :-)
-- 
-- "Self-interest has no place in society" -- Sandy Cuney, HCI, 5/6/94


-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 94 08:57:52 CST
From:      bruss@inland.com (Trevor Bruss)
To:        comp.protocols.tcp-ip
Subject:   Determination of server port from client's side??

   I'm trying to find out if there is a way to determine which port my server
is running on from another platform.  Let me clarify:
   I'm trying to communicate from a VAX (Multinet) client to a SUN (whatever
version TCP/IP) server.  I'm using sockets to make the connection.  I've set
the server's port to 0 which from what I understand polls for an open port.  I
want the client to be able to determine which port to use but I don't know how. 
I haven't run across anything in the Multinet manual so I was hoping someone
here could help me.
-- 
Trevor T. Bruss      Carpe Viam--- Sieze the road!!                __o     o
bruss@research.inland.com  (219) 399-4910 -- Work    ..._/\o_      \<,    .<,
			   (219) 271-0371 -- Home   """"~~~~~"  (+)/ (+)  />

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 03:16:57 GMT
From:      bandy@ecst.csuchico.edu (Brett Edward Bandy)
To:        comp.protocols.tcp-ip
Subject:   Running TCP/IP

    I am trying to setup an ethernet network with two other machines.  
One of the machines is running OS/2 and the other two are running DOS/
Windows.  I am in need of a network operating system that will allow us to 
link the three machines.  Money is a prime factor in the decision (this is
just an experiment, so the cheaper the better).  Performance is not the major
concern. Any information would be greatly appeciated.

                             Thanks in advance,
                                 Brett Bandy


-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 12:24 MST
From:      gavron@hearts.aces.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection establishment

In article <1994Aug1.115848.19318@athen.mch.sni.de>, Emil.Naepflein@mch.sni.de (Emil Naepflein) writes...
# 
#I need help from a TCP expert. The problem is, that sometimes the
#ACK during connection establishment is lost. After that the client side

Which ACK?  

#is hanging in ESTABLISHED state, the server side has closed the conntection.

Then one of them has violated the spec.

#I don't find any information about this problem in the TCP RFC and in
#Richard Stevens book. May be there is someone which can help me.

Look at the TCP RFC again.  RFC 793 page 23.

#Here is a simple description of the problem:
#SERVER					CLIENT
#					send SYN
#send SYN,ACK
#					send ACK (this ACK is lost)
#send SYN,ACK
#					no answer from client
#send SYN,ACK
#					no answer from client
#server closes connection without sending RST
#					client stayes in ESTABLISHED
# 
# 
#Here are some questions I need an answer for:
# 
#1. Should the client send an ACK after receiving SYN,ACK in ESTABLISHED state?

YES.  Always acknowledge all seen packets.

#2. Should the client send a RST after receiving SYN,ACK in ESTABLISHED state?

NO.  Duplicate acks are ok, and it's an old SYN (from seq numbers).

#3. Should the server really do the retransmits?

YES.  These are unacknowledged packets

#4. Should the server send a RST after the retransmits?

Well what we're seeing is not covered in the protocol state machine.
The server is in SYN RCVD from which it can CLOSE/snd FIN or rcv ACK.
If it chooses to "eliminate" the socket then it should send an RST, 
but that's not covered in 793.

In fact, I'd venture that doing this is a violation of 793.

#5. What is the behaviour of other TCP implementations in this situation?

Hang in SYN RCVD...

#Emil Naepflein

Ehud

--
Ehud Gavron        (EG76)
gavron@aces.com

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 1994 05:57:30 GMT
From:      brantk@adcmail.atlas.com (brantk)
To:        comp.os.386bsd.questions,comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Problems with FreeBSD SLIP (can telnet/cannot ping)


I'm working on adding my small network to the Internet.  Connection is
made via a 14.4Kbps dialup SLIP connection.  I can telnet out, ftp,
you name it.  I just can't ping hosts outside of my own local network.
Strange, considering I can reach them via telnet.

Here's a few facts to consider:

* The IP address of my local net is 199.26.157.x, which is an "official"
class C assigned by the InterNIC.

* My domain is vertigo.com, this is NOT official, and is not used outside
my local network (not until it's official, anyways).

* I am connecting to my provider's NetBlazer, which uses Dynamic IP. (I
get a different IP address every time I dial up).

* My gateway machine is an Intel-based machine running FreeBSD 1.1.0(Beta).
All of my tests were run from the gateway (everest).

* Configuration and routing are done as follows:
	slattach -s 38400 /dev/ttyd0
	ifconfig sl0 ${IP_ADDRESS} up
	route flush
	route add default ${IP_ADDRESS}
 
Any ideas on where I should continue looking?  I can't find anything
abnormal in any of my configuration files.



-- 
brantk@atlas.com | "Electricity is made up of very small particles called
Atlas Telecom    |  electrons, which you cannot see unless you have been
Portland, OR     |  drinking."
       --- This message printed with 100% recycled electrons ---

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 18:21:28 -0700
From:      bmk@teleport.com (bmk)
To:        comp.os.386bsd.questions,comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: Problems with FreeBSD SLIP (can telnet/cannot ping)

In article <31j51q$97e@newhub.xylogics.com>,
James Carlson <carlson@xylogics.com> wrote:
>In article <1994Aug1.055730.4188@atlas.com>, brantk@adcmail.atlas.com (brantk) writes:
>|> 	slattach -s 38400 /dev/ttyd0
>
>They probably have ICMPs turned off on your line.  This is a common
>thing to do to avoid wasting bandwidth on them.
>

I am feeling very, very stupid.  :)

Yes, it is disabled ICMP, but not at the provider end.  It's on my end.
(The slattach command that I put in the original message is NOT the one
I currently use, it's in an old version of my slip.connect script.)

Duh.

Thanks to everyone who helped.

Brant "I'm not a newbie, but sometimes I look like one" Katkansky

-- 
bmk@teleport.com  | "You need only reflect that one of the best ways to get 
Portland, OR      | yourself a reputation as a dangerous citizen these days is
                  | to go about repeating the very phrases which our founding
                  | fathers used in the struggle for independence."-C.A. Beard

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 21:11:57 -0700
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   Re: tunneling

electro@engg.ksu.edu (Eric L Patterson) writes:

>Hi.  Does anyone have any information on tcp "tunneling"?
>I have a slip connection to our campus, and a small network
>at home.  However, our slip admin won't let the slip router
>run rip (allowing me to route packets for any of my machines
>at home thru the slip connection).  If i try to route an ip
>other than that of the actual slip ip, the slip router
>bounces them back.  Is there a way to encapsulate and
>de/encapsulate them at either end of the slip line?
>Thanks
>-- 
>Eric Patterson        |  Internet - electro@engg.ksu.edu 
>2435 Buttonwood Dr.   |  Bitnet   - electro@ksuvm.ksu.edu
>Manhattan, KS  66502  |

Humm, the only thing that RIP will get ya is the routing tables
(reach LAN X by Y IP address).  Why not use a 'default route'.
ie LAN 0.0.0.0 by Y IP address (where as Y = the IP address
on your SLIP server).
-- 
    /|                          Tom Brink
 \`o.0'                         tbrink@crl.com
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 94 10:14:06 GMT
From:      sheela@eden.rutgers.edu (Isis Leslie)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: PCBridge as link to SLIP/PPP provider WON'T WORK

I didn't include the original article because is was rather long
(not that it wasn't worthy of repeating though)

But anyway your rather narrow definition of a bridge goes against
almost everything I've been taught.
 
When we run bridges (and we run close to a hundred of them of all types)
things work pretty much as was described in the original post/question
IP packets encapsulated in a standard medai specific packet, in this
case ethernet, ip packets go out the slip line in conventional or
compressed header format, hit the other half of the bridge which then
encapsulated the datagram in a ethernet packet (which of course
reflects it's own address) and it goes out it's own ethernet interfac.

Onre half of the bridge could be token ring to slip, the other ethernet
to slip and you wouldn't see token ring packets getting passed to the ethernet
and vice versa.
 
His internet service provider must be using some sort of media and that
media has to support something unless it works by magic, it might be
ethernet, tokenring or whatever.

lastly unless one goes to try and encasulate the ethernet datagram in an ip
packet, the media specific ethernet packet wouldn't appear on the otherside
anyway.

Lots of people use PCRoute/Bridge to connect to their internet service 
providers all over the world and it works the same everywhere, a machine
generates an ip packet, it gets encapsulated in the media packet, goes in
the interface on the bridge, the ip packet is extracted, put into slip 
framing, trqansmitted over the slip line (esp since SLIP has no provision
for anything but IP) gets to the otherside bridge and he datagram is put into
another media specifc apcket and sent to it's destination.

In short, PC Route in it's default compiles will do exactly what he wants,
though many would argue that KA9Q would do it better and Linux would be
more versatile.

Hint-Don't be duped into thinking that you should enable the slip interface
with "ethernet" emulation...it does nothing as far as PC bridge is concerned
at makes for overhead...

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 94 17:27:30 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <072894170213Rnf0.78@dmrt-2.dmrt.nl>, marco@dmrt-2.dmrt.nl writes:
> sej@psycfrnd.interaccess.com (Stephen Johnson) writes:
> 
>>I have not had good luck running Novell servers as routers with
>>different subnet masks on different interfaces. Might be my problem,
>>might not :)
> 
> No, it's not your problem :-). Only the latest TCPIP.NLM (TCP187.EXE on 
> ftp.novell.com) adds implicit support for this.
>                                                
> 			Marco.
------------
	Well, it doesn't either. While internally there are such comments
in the file, left over from the MultiProtocol Router product, we still use
one subnet mask for all ports for the regular TCPIP.NLM. That and Proxy
ARP are the two frequently made requests.
	Also note that RIP does not support subnet masks, which means
different masks on different nets makes things rather confusing with RIP.
	Maybe Don Provan would care to elaborate and correct, since he's
a party of the first part.
	Joe D.

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 94 11:58:48 GMT
From:      egn@athen.mch.sni.de (Emil Naepflein)
To:        comp.protocols.tcp-ip
Subject:   TCP connection establishment


I need help from a TCP expert. The problem is, that sometimes the
ACK during connection establishment is lost. After that the client side
is hanging in ESTABLISHED state, the server side has closed the conntection.
I don't find any information about this problem in the TCP RFC and in
Richard Stevens book. May be there is someone which can help me.


Here is a simple description of the problem:

SERVER					CLIENT
					send SYN
send SYN,ACK
					send ACK (this ACK is lost)
send SYN,ACK
					no answer from client
send SYN,ACK
					no answer from client
server closes connection without sending RST
					client stayes in ESTABLISHED


Here are some questions I need an answer for:

1. Should the client send an ACK after receiving SYN,ACK in ESTABLISHED state?

2. Should the client send a RST after receiving SYN,ACK in ESTABLISHED state?

3. Should the server really do the retransmits?

4. Should the server send a RST after the retransmits?

5. What is the behaviour of other TCP implementations in this situation?


Looking forward to your answers

Emil Naepflein

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 1994 12:55:52 GMT
From:      gvrooij@ms.philips.nl (Guido van Rooij)
To:        comp.os.386bsd.questions,comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: Problems with FreeBSD SLIP (can telnet/cannot ping)

brantk (brantk@adcmail.atlas.com) wrote:

: * I am connecting to my provider's NetBlazer, which uses Dynamic IP. (I
: get a different IP address every time I dial up).


Maybe this SLIP connection is doen withn a NOICMP alike option on the
provider's side of the connection?

-Guido

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 94 12:59:21 GMT
From:      friant@rsm.enst-bretagne.fr
To:        comp.protocols.tcp-ip
Subject:   Receiver for pktdrv in C or asm

I would like to have informations about the programming of a packet driver receive
routine (C or assembler). I work on PC and I use SMC cards. I have problems with the use
of access_type function that normally initiates access to packets by calling twice the
receiver routine. 

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 22:18:26 -0500
From:      phil@zeus.fasttax.com (Phil Howard)
To:        comp.protocols.tcp-ip
Subject:   traceroute hangs

I suspect this is a software problem, but no other newsgroup stood out
as obvious as this one since so many of you probably use it at one time
or another.  The problem occurs on all platforms and in a few different
versions of traceroute.

Normally when a host is not responding at a given level, traceroute will
display a "*" after some timeout period, usually 3 seconds.  Also, if it
is resolving addresses into hostnames and the DNS does not respond, it
can hang there, and for quite some time.  I wish it would just give up
after the same 3 seconds and just print the IP address like it does when
it knows there is no name.

But the real problem is this:

Sometimes, even when I use "-n" to give only IP addresses, traceroute will
just hang and do nothing.  Leaving it alone it never does anything ever
again.  I left one over a weekend once.  It was still hung when I got back.

What would cause THIS particular hang?

If this had happened on a particular host I'd readily blame that one.
However this has happened on nearly every type of platform I have ever
used as far as I can remember.  It typically hangs at the same point
many times when it does (which would have suggested the DNS problem had
I not used "-n").  Currently this hang is happening at a Novell server
which is pretending to be a router.  That server never returns a time
expired and I see the usual "* * *" about 60% of the time.  About 40%
of the time it freezes up at that point never even showing the hop number.

Any ideas?

Or is this really just a programming problem with traceroute?

Any better version around that is fixed in this regard (for sure, i.e. has
acknowledged it as a fixed problem) and portable over many unix platforms?
-- 
Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
CLR/Fast-Tax            | utility?
phil@fasttax.com        |

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 1994 14:01:54 GMT
From:      dch2@netcom.com (D. Hobbs)
To:        comp.protocols.tcp-ip
Subject:   Oops! (was: Re: Unix tcp-ip to IBM Mainframe file transfer)

Sorry netters.  I thought I had replied via email, not followed up.
I guess the f and r keys are close together...

D.
-- 
David Hobbs
dch2@netcom.com, 71175.166@compuserve.com
All typos are my own.  The spelling errors are someone else's.
"I am Fudd of Borg.  Pwepare to be assimiwated."

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 22:45:23 -0500
From:      phil@zeus.fasttax.com (Phil Howard)
To:        comp.protocols.tcp-ip
Subject:   Wanted: PD router for PC with TR

I'm looking for a public domain (GNU licensing OK) router for a PC that
includes token ring support.  I only need to route IP (no IPX or anything
else).  Firewall filtering would be a plus but is not necessary.  The
ability to configure static routes with a netmask specified separate for
each static route entry would be a definite plus.  RIP support is nice
but I don't expect to use it if I can do what I need to do with static.
Oh, and ethernet is needed, too, but I started by assuming all have it.
-- 
Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
CLR/Fast-Tax            | utility?
phil@fasttax.com        |

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 22:52:04 -0500
From:      phil@zeus.fasttax.com (Phil Howard)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

sej@psycfrnd.interaccess.com (Stephen Johnson) writes:

>I have not had good luck running Novell servers as routers with
>different subnet masks on different interfaces. Might be my problem,
>might not :)

I've run into this problem with other routers, too (no brand names will
be mentioned until I verify that it is not my fault).  In general I find
most routers have at least 1 or 2 "gotchas" in their configurability.

I've even seen routers that will ONLY support subnet masks on 8-bit
boundaries, so class C cannot even be subnetted with them.  Class B
has only one choice, and class A is limited to 2 choice (I think).

A few will let you do some things with a netmask specified by number
of bits in the network part and assume they are all high order bits.
I don't know of any that let you do much with explicit netmasks that
do not have all the 1 bits together.
-- 
Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
CLR/Fast-Tax            | utility?
phil@fasttax.com        |

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 14:38:16 GMT
From:      bortz@cnam.cnam.fr (Stephane Bortzmeyer)
To:        comp.unix.osf.osf1,comp.protocols.tcp-ip
Subject:   TCP connection problem and how to interpret netstat output?

Hello,

I have a strange TCP problem on a DEC Alpha + OSF/1 server. The machine 
is an HTTP server (http://web.cnam.fr/) and has an important load 
(between 200 000 and 300 000 files transferred per day).

The symptom is the following: most of the time, the server (which has, 
at the present time, almost no other tasks, expect low-priority CPU-
intensive jobs) replies instantaneously to the clients on the same 
Ethernet. But very often we see delays of 10, 20, 40 seconds and often 
Mosaic times out.

The problem doesn't depend on the client software: Mosaic, Lynx, url_get, 
raw telnet neither on the client machine: DECstation/Ultrix, Macintosh.

I tried to investigate with netstat and lsof. At peak hours, netstat 
typically sees 200 connections, more than the half of them being in 
TIME_WAIT. lsof sees typically 40-60 descriptors open, which means 
15-20 clients, the average number of simultaneous transfers.
 
So, what can I try? I assumed one connection saw by netstat means 
one socket reserved by the kernel (am I wrong?). I thought we were 
experiencing a resource starvation and that the kernel was waiting 
for a free socket. I tried to increase the MAXUSERS parameter in 
the config file (to 2048!) but I'm still blocked at the same point.

Here is a typical output from netstat when we have the problem:

web-server> netstat -f inet -n | grep '163\.173\.128\.15\.80'
tcp        0      0  163.173.128.15.80      160.9.128.12.1027      ESTABLISHED
tcp        0      0  163.173.128.15.80      130.46.14.113.1666     SYN_RCVD
tcp        0      0  163.173.128.15.80      165.220.16.2.2054      ESTABLISHED
tcp        0      0  163.173.128.15.80      158.152.31.209.1937    SYN_RCVD
tcp        0  22506  163.173.128.15.80      147.188.32.209.36704   FIN_WAIT_1
tcp        0  21295  163.173.128.15.80      150.227.34.39.34539    FIN_WAIT_1
tcp        0   3599  163.173.128.15.80      128.8.147.97.1046      FIN_WAIT_1
tcp      532  36584  163.173.128.15.80      130.207.121.91.33025   ESTABLISHED
tcp        0  12469  163.173.128.15.80      152.78.72.70.1071      FIN_WAIT_1
tcp        0      0  163.173.128.15.80      129.187.153.103.2354   ESTABLISHED
tcp        0      0  163.173.128.15.80      156.98.66.40.1154      ESTABLISHED
tcp      565  34976  163.173.128.15.80      170.54.252.247.1170    ESTABLISHED
tcp        0      0  163.173.128.15.80      152.78.72.70.1070      TIME_WAIT
tcp     1106  35431  163.173.128.15.80      192.32.243.98.4765     ESTABLISHED
tcp        0    955  163.173.128.15.80      192.82.158.150.2961    FIN_WAIT_1
tcp        0   9229  163.173.128.15.80      140.170.61.41.1376     FIN_WAIT_1
tcp        0   3009  163.173.128.15.80      139.17.51.46.2161      FIN_WAIT_1
tcp        0  15736  163.173.128.15.80      134.20.13.161.1862     FIN_WAIT_1
tcp        0      0  163.173.128.15.80      129.41.144.1.1239      TIME_WAIT
tcp        0      0  163.173.128.15.80      192.225.72.59.42329    TIME_WAIT
tcp        0   3515  163.173.128.15.80      156.98.65.52.1129      FIN_WAIT_1
tcp      408      0  163.173.128.15.80      134.68.32.53.1026      ESTABLISHED
tcp        0      0  163.173.128.15.80      130.127.244.96.25009   FIN_WAIT_1
tcp        0      0  163.173.128.15.80      170.54.252.247.1682    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      129.187.153.103.2353   TIME_WAIT
tcp        0      0  163.173.128.15.80      130.111.114.164.8929   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.222.37.18.1922     TIME_WAIT
tcp        0      0  163.173.128.15.80      147.188.32.209.36702   TIME_WAIT
tcp        0   3549  163.173.128.15.80      129.13.113.98.3533     FIN_WAIT_1
tcp        0      0  163.173.128.15.80      147.163.10.94.2518     TIME_WAIT
tcp        0      0  163.173.128.15.80      156.98.66.40.1153      TIME_WAIT
tcp        0      0  163.173.128.15.80      140.170.61.41.1375     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.6.58.134.2141      TIME_WAIT
tcp        0      0  163.173.128.15.80      131.169.30.39.4930     TIME_WAIT
tcp        0      0  163.173.128.15.80      128.154.20.33.1187     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.237.234.37.1032    TIME_WAIT
tcp        0      0  163.173.128.15.80      131.254.42.37.1664     TIME_WAIT
tcp        0      0  163.173.128.15.80      128.159.186.80.2528    TIME_WAIT
tcp        0      0  163.173.128.15.80      131.254.42.37.1663     TIME_WAIT
tcp       39      0  163.173.128.15.80      193.112.185.123.31432  ESTABLISHED
tcp        0      0  163.173.128.15.80      192.195.245.182.1115   TIME_WAIT
tcp        0      0  163.173.128.15.80      134.20.13.161.1861     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.237.234.37.1031    TIME_WAIT
tcp        0   1155  163.173.128.15.80      198.202.222.168.1046   FIN_WAIT_1
tcp        0      0  163.173.128.15.80      199.100.7.6.3073       TIME_WAIT
tcp        0      0  163.173.128.15.80      136.200.162.106.3639   TIME_WAIT
tcp        0      0  163.173.128.15.80      147.162.72.150.4473    TIME_WAIT
tcp        0      0  163.173.128.15.80      139.17.51.46.2160      TIME_WAIT
tcp        0      0  163.173.128.15.80      147.162.72.150.4471    TIME_WAIT
tcp        0      0  163.173.128.15.80      192.195.245.182.1114   TIME_WAIT
tcp        0      0  163.173.128.15.80      160.9.128.12.1026      TIME_WAIT
tcp        0      0  163.173.128.15.80      129.6.58.134.2140      TIME_WAIT
tcp        0      0  163.173.128.15.80      192.225.72.59.42328    TIME_WAIT
tcp        0  29327  163.173.128.15.80      196.6.251.120.1616     FIN_WAIT_1
tcp        0      0  163.173.128.15.80      131.227.113.140.3604   TIME_WAIT
tcp      336  38279  163.173.128.15.80      132.74.1.27.1039       ESTABLISHED
tcp      367  34184  163.173.128.15.80      157.253.116.22.29357   ESTABLISHED
tcp        0      0  163.173.128.15.80      148.198.10.5.4785      TIME_WAIT
tcp        0      0  163.173.128.15.80      160.9.128.12.1025      TIME_WAIT
tcp        0      0  163.173.128.15.80      158.23.45.19.33416     TIME_WAIT
tcp        0      0  163.173.128.15.80      163.173.129.0.2085     TIME_WAIT
tcp        0      0  163.173.128.15.80      163.173.80.135.32945   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      163.173.129.0.2084     TIME_WAIT
tcp        0      0  163.173.128.15.80      192.32.243.98.4764     TIME_WAIT
tcp      394      0  163.173.128.15.80      137.195.12.233.29707   ESTABLISHED
tcp        0      0  163.173.128.15.80      198.202.222.168.1045   TIME_WAIT
tcp        0      0  163.173.128.15.80      156.98.65.52.1128      TIME_WAIT
tcp        0      0  163.173.128.15.80      161.134.190.45.1167    TIME_WAIT
tcp        0      0  163.173.128.15.80      129.228.59.15.2242     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.228.44.62.1032     TIME_WAIT
tcp     1161  25176  163.173.128.15.80      192.249.47.22.3703     ESTABLISHED
tcp        0  35675  163.173.128.15.80      192.58.206.20.3235     FIN_WAIT_1
tcp        0      0  163.173.128.15.80      131.120.50.70.3555     TIME_WAIT
tcp        0      0  163.173.128.15.80      131.169.30.39.4911     TIME_WAIT
tcp        0      0  163.173.128.15.80      192.58.206.20.3232     TIME_WAIT
tcp        0      0  163.173.128.15.80      128.222.37.18.1918     TIME_WAIT
tcp        0      0  163.173.128.15.80      140.170.61.41.1374     TIME_WAIT
tcp        0  12304  163.173.128.15.80      192.135.78.32.2399     FIN_WAIT_1
tcp        0      0  163.173.128.15.80      156.98.65.52.1127      TIME_WAIT
tcp        0   8677  163.173.128.15.80      131.182.240.14.1698    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      152.78.72.70.1069      TIME_WAIT
tcp        0      0  163.173.128.15.80      134.68.13.10.1328      TIME_WAIT
tcp        0      0  163.173.128.15.80      150.148.36.172.1103    TIME_WAIT
tcp        0      0  163.173.128.15.80      152.78.72.70.1068      TIME_WAIT
tcp        0  14425  163.173.128.15.80      144.96.128.80.2946     FIN_WAIT_1
tcp        0      0  163.173.128.15.80      129.237.234.37.1030    TIME_WAIT
tcp        0      0  163.173.128.15.80      138.38.32.34.2570      TIME_WAIT
tcp        0      0  163.173.128.15.80      150.148.36.172.1101    TIME_WAIT
tcp        0      0  163.173.128.15.80      193.78.244.90.41377    TIME_WAIT
tcp        0      0  163.173.128.15.80      147.188.32.209.36701   TIME_WAIT
tcp        0      0  163.173.128.15.80      128.155.30.72.1157     TIME_WAIT
tcp        0      0  163.173.128.15.80      131.169.30.39.4902     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.237.234.37.1029    TIME_WAIT
tcp        0      0  163.173.128.15.80      161.134.190.45.1165    TIME_WAIT
tcp        0      0  163.173.128.15.80      138.38.32.34.2568      TIME_WAIT
tcp        0      0  163.173.128.15.80      147.188.32.209.36700   TIME_WAIT
tcp        0      0  163.173.128.15.80      128.42.76.12.1538      FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.159.186.80.2526    TIME_WAIT
tcp        0      0  163.173.128.15.80      129.187.153.100.3653   TIME_WAIT
tcp        0      0  163.173.128.15.80      192.32.243.98.4762     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.241.4.6.4254       TIME_WAIT
tcp        0      0  163.173.128.15.80      152.78.65.92.1221      ESTABLISHED
tcp        0      0  163.173.128.15.80      134.120.10.236.1170    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      192.135.78.32.2398     TIME_WAIT
tcp        0      0  163.173.128.15.80      131.254.42.37.1662     TIME_WAIT
tcp        0      0  163.173.128.15.80      141.24.100.16.1813     TIME_WAIT
tcp        0      0  163.173.128.15.80      192.134.15.70.1122     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.241.4.6.4253       TIME_WAIT
tcp        0      0  163.173.128.15.80      140.175.20.221.1487    TIME_WAIT
tcp        0      0  163.173.128.15.80      140.170.61.41.1373     TIME_WAIT
tcp        0  13163  163.173.128.15.80      129.193.29.122.1036    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      140.170.61.41.1372     TIME_WAIT
tcp        0      0  163.173.128.15.80      198.202.222.168.1044   TIME_WAIT
tcp        0      0  163.173.128.15.80      156.98.65.52.1126      TIME_WAIT
tcp        0      0  163.173.128.15.80      128.165.24.227.1053    TIME_WAIT
tcp        0      0  163.173.128.15.80      192.16.74.179.22977    TIME_WAIT
tcp        0      0  163.173.128.15.80      129.187.153.103.2352   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      131.254.42.37.1661     TIME_WAIT
tcp        0      0  163.173.128.15.80      192.135.78.32.2397     TIME_WAIT
tcp        0      0  163.173.128.15.80      128.222.37.18.1916     TIME_WAIT
tcp        0      0  163.173.128.15.80      147.188.32.209.36698   TIME_WAIT
tcp        0      0  163.173.128.15.80      155.82.167.11.2110     TIME_WAIT
tcp        0      0  163.173.128.15.80      128.159.104.85.1038    TIME_WAIT
tcp        0      0  163.173.128.15.80      129.6.58.134.2139      TIME_WAIT
tcp        0      0  163.173.128.15.80      131.254.42.37.1660     TIME_WAIT
tcp        0      0  163.173.128.15.80      132.177.131.120.1208   TIME_WAIT
tcp        0      0  163.173.128.15.80      131.254.42.37.1659     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.93.221.138.1060    TIME_WAIT
tcp        0      0  163.173.128.15.80      128.194.71.200.1497    TIME_WAIT
tcp        0      0  163.173.128.15.80      192.148.243.40.1253    TIME_WAIT
tcp      996  33328  163.173.128.15.80      198.64.192.1.1479      ESTABLISHED
tcp        0      0  163.173.128.15.80      131.169.30.39.4893     TIME_WAIT
tcp        0      0  163.173.128.15.80      199.100.7.6.3071       TIME_WAIT
tcp        0      0  163.173.128.15.80      128.165.24.227.1052    TIME_WAIT
tcp        0      0  163.173.128.15.80      198.202.222.168.1043   TIME_WAIT
tcp        0  30163  163.173.128.15.80      148.197.221.75.1041    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      131.131.201.243.1216   TIME_WAIT
tcp        0      0  163.173.128.15.80      131.254.42.37.1658     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.187.153.100.3652   TIME_WAIT
tcp        0      0  163.173.128.15.80      128.159.104.85.1037    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      131.254.42.37.1657     TIME_WAIT
tcp        0      0  163.173.128.15.80      152.78.72.70.1067      TIME_WAIT
tcp        0      0  163.173.128.15.80      152.1.22.82.1271       TIME_WAIT
tcp        0      0  163.173.128.15.80      156.98.65.52.1125      TIME_WAIT
tcp        0  22769  163.173.128.15.80      129.237.247.243.1442   FIN_WAIT_1
tcp        0      0  163.173.128.15.80      131.169.30.39.4890     TIME_WAIT
tcp        0      0  163.173.128.15.80      140.175.20.221.4033    TIME_WAIT
tcp        0      0  163.173.128.15.80      128.103.25.84.1638     TIME_WAIT
tcp        0      0  163.173.128.15.80      131.251.42.203.4914    TIME_WAIT
tcp        0      0  163.173.128.15.80      199.100.7.6.3069       TIME_WAIT
tcp        0      0  163.173.128.15.80      192.225.72.59.42327    TIME_WAIT
tcp        0      0  163.173.128.15.80      140.170.61.41.1371     TIME_WAIT
tcp        0      0  163.173.128.15.80      192.135.78.32.2396     TIME_WAIT
tcp        0      0  163.173.128.15.80      192.225.72.59.42326    TIME_WAIT
tcp        0      0  163.173.128.15.80      128.209.10.19.2689     TIME_WAIT
tcp        0      0  163.173.128.15.80      192.148.243.40.1251    TIME_WAIT
tcp        0  10911  163.173.128.15.80      128.95.20.8.1489       FIN_WAIT_1
tcp        0      0  163.173.128.15.80      132.177.131.120.1207   TIME_WAIT
tcp        0      0  163.173.128.15.80      128.8.129.33.62385     TIME_WAIT
tcp        0      0  163.173.128.15.80      140.170.61.41.1370     TIME_WAIT
tcp        0      0  163.173.128.15.80      132.177.131.162.1698   TIME_WAIT
tcp        0      0  163.173.128.15.80      131.131.201.243.1215   TIME_WAIT
tcp        0      0  163.173.128.15.80      140.175.20.221.4369    TIME_WAIT
tcp        0      0  163.173.128.15.80      193.112.185.123.31010  TIME_WAIT
tcp        0      0  163.173.128.15.80      152.78.72.70.1066      TIME_WAIT
tcp        0      0  163.173.128.15.80      138.20.30.5.2420       TIME_WAIT
tcp        0      0  163.173.128.15.80      152.78.65.92.1220      TIME_WAIT
tcp        0      0  163.173.128.15.80      192.195.245.182.1113   TIME_WAIT
tcp        0      0  163.173.128.15.80      156.98.65.52.1124      TIME_WAIT
tcp        0      0  163.173.128.15.80      129.237.234.37.1028    TIME_WAIT
tcp        0      0  163.173.128.15.80      192.135.78.32.2395     TIME_WAIT
tcp        0      0  163.173.128.15.80      192.58.206.20.3215     TIME_WAIT
tcp        0      0  163.173.128.15.80      134.244.121.13.1330    TIME_WAIT
tcp        0      0  163.173.128.15.80      129.12.21.27.2922      TIME_WAIT
tcp        0      0  163.173.128.15.80      151.110.32.87.2867     TIME_WAIT
tcp        0      0  163.173.128.15.80      131.254.42.37.1656     TIME_WAIT
tcp        0      0  163.173.128.15.80      150.148.36.172.1099    TIME_WAIT
tcp        0      0  163.173.128.15.80      131.227.113.140.3599   TIME_WAIT
tcp        0      0  163.173.128.15.80      132.177.131.162.1826   TIME_WAIT
tcp        0      0  163.173.128.15.80      129.109.48.166.1081    TIME_WAIT
tcp        0      0  163.173.128.15.80      150.148.36.172.1097    TIME_WAIT
tcp        0      0  163.173.128.15.80      193.112.185.123.30888  TIME_WAIT
tcp        0      0  163.173.128.15.80      144.96.128.80.2945     TIME_WAIT
tcp        0      0  163.173.128.15.80      152.78.65.92.1218      TIME_WAIT
tcp        0      0  163.173.128.15.80      147.162.72.150.4466    TIME_WAIT
tcp        0      0  163.173.128.15.80      198.49.144.1.2461      TIME_WAIT
tcp        0      0  163.173.128.15.80      128.95.20.8.1041       TIME_WAIT
tcp        0      0  163.173.128.15.80      130.192.202.150.1399   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      129.237.247.243.1409   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      139.177.254.208.1186   TIME_WAIT
tcp        0  11544  163.173.128.15.80      149.149.19.105.7139    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      199.100.7.6.3067       TIME_WAIT
tcp        0      0  163.173.128.15.80      130.88.14.17.4344      TIME_WAIT
tcp        0      0  163.173.128.15.80      131.115.50.17.1410     TIME_WAIT
tcp        0      0  163.173.128.15.80      130.161.158.8.1409     TIME_WAIT
tcp        0      0  163.173.128.15.80      193.78.244.90.41376    TIME_WAIT
tcp     1106  27792  163.173.128.15.80      128.49.112.7.2625      ESTABLISHED
tcp        0      0  163.173.128.15.80      192.195.245.182.1112   TIME_WAIT
tcp        0      0  163.173.128.15.80      156.98.66.40.1151      TIME_WAIT
tcp        0      0  163.173.128.15.80      150.227.34.39.34535    TIME_WAIT
tcp        0  22365  163.173.128.15.80      198.88.100.2.1111      FIN_WAIT_1
tcp        0      0  163.173.128.15.80      193.112.185.123.30446  TIME_WAIT
tcp        0      0  163.173.128.15.80      130.167.14.99.1618     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.187.124.7.1484     TIME_WAIT
tcp        0      0  163.173.128.15.80      128.143.20.30.3471     TIME_WAIT
tcp        0      0  163.173.128.15.80      128.165.24.227.1051    TIME_WAIT
tcp        0      0  163.173.128.15.80      129.217.212.21.3642    TIME_WAIT
tcp        0      0  163.173.128.15.80      130.183.60.91.3413     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.237.234.37.1027    TIME_WAIT
tcp        0  11981  163.173.128.15.80      143.158.200.18.3876    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      129.193.29.122.1035    TIME_WAIT
tcp      374  37320  163.173.128.15.80      134.243.200.143.5234   ESTABLISHED
tcp        0  17535  163.173.128.15.80      130.75.50.144.3915     CLOSING
tcp        0      0  163.173.128.15.80      141.24.100.16.1812     TIME_WAIT
tcp        0      0  163.173.128.15.80      134.241.56.58.1105     TIME_WAIT
tcp        0  19159  163.173.128.15.80      192.153.124.29.2097    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      129.109.48.166.1078    FIN_WAIT_2
tcp        0  20501  163.173.128.15.80      129.13.113.96.1899     FIN_WAIT_1
tcp        0      0  163.173.128.15.80      129.200.221.8.34657    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      192.82.158.150.54657   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      165.220.16.2.2053      TIME_WAIT
tcp        0  15371  163.173.128.15.80      155.41.120.18.30993    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      134.176.2.8.2040       TIME_WAIT
tcp        0      0  163.173.128.15.80      164.11.100.10.1635     TIME_WAIT
tcp        0      0  163.173.128.15.80      129.187.153.103.2350   TIME_WAIT
tcp        0      0  163.173.128.15.80      134.120.10.236.1745    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      192.20.239.131.1235    TIME_WAIT
tcp        0      0  163.173.128.15.80      198.202.222.168.1026   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      132.74.1.27.1037       TIME_WAIT
tcp        0      0  163.173.128.15.80      192.16.74.179.17969    FIN_WAIT_2
tcp      596  37928  163.173.128.15.80      163.185.21.171.49537   ESTABLISHED
tcp        0      0  163.173.128.15.80      198.108.64.112.1057    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      129.237.247.243.1170   FIN_WAIT_2
tcp        0   8045  163.173.128.15.80      138.172.19.101.1042    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      141.173.197.13.39665   FIN_WAIT_2
tcp      996  33376  163.173.128.15.80      128.219.17.24.2108     ESTABLISHED
tcp        0      0  163.173.128.15.80      146.186.112.70.2321    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      137.65.43.32.28145     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      158.152.31.209.1186    FIN_WAIT_2
tcp        0   1017  163.173.128.15.80      132.146.177.20.33580   FIN_WAIT_1
tcp        0      0  163.173.128.15.80      129.237.234.37.1049    FIN_WAIT_1
tcp        0      0  163.173.128.15.80      134.120.10.236.1938    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      148.197.221.75.1034    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      129.200.221.8.47969    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      158.152.31.209.1858    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      157.187.20.204.1051    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      139.169.63.104.10497   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      138.172.19.101.1040    TIME_WAIT
tcp        0      0  163.173.128.15.80      137.65.43.32.50337     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.60.205.137.42785   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.96.99.214.1074     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      131.225.13.25.1061     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      131.182.240.14.1938    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.60.205.137.12113   FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.60.205.137.58817   FIN_WAIT_2
tcp      996  25264  163.173.128.15.80      143.196.9.66.2813      ESTABLISHED
tcp        0  33421  163.173.128.15.80      17.255.28.72.1042      FIN_WAIT_1
tcp        0      0  163.173.128.15.80      128.8.129.33.28993     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      130.127.244.96.5665    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      198.108.64.112.1058    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      130.46.14.113.1538     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.42.76.12.1489      FIN_WAIT_2
tcp        0      0  163.173.128.15.80      193.64.195.140.1115    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.60.205.137.5889    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      198.108.64.112.1490    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.96.99.214.1490     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      130.92.71.197.3923     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.118.110.228.45025  FIN_WAIT_2
tcp        0      0  163.173.128.15.80      128.96.99.214.1729     FIN_WAIT_2
tcp        0      0  163.173.128.15.80      129.239.66.174.6529    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      140.170.88.48.32129    FIN_WAIT_2
tcp        0      0  163.173.128.15.80      198.62.143.62.545      SYN_RCVD
tcp        0   2278  163.173.128.15.80      144.58.85.92.1073      FIN_WAIT_1
tcp        0  37576  163.173.128.15.80      130.183.60.91.3326     FIN_WAIT_1
tcp        0   1465  163.173.128.15.80      149.164.187.57.1922    FIN_WAIT_1

From what I've read in RFC 793, I deduce TIME_WAIT is a mandatory step, and 
that we have to stay in this state for a quite long duration, independant 
of the processor speed.

Here is a typical output from lsof in the same conditions:

web-server> lsof -n -a -uhttp -H -P
COMMAND     PID     USER   FD   TYPE       DEVICE   SIZE/OFF  INODE NAME
httpd5    11431     http    0u  inet   0x93bf1700        0x0    TCP 163.173.128.15:80->157.253.116.22:29357157.253.116.22:44402
httpd5    11431     http    1u  inet   0x93bf1700        0x0    TCP 163.173.128.15:80->157.253.116.22:29357157.253.116.22:44402
httpd5    11431     http    2u  inet   0x93bf1700        0x0    TCP 163.173.128.15:80->157.253.116.22:29357157.253.116.22:44402
httpd5    11692     http    0u  inet   0x93d12500        0x0    TCP 163.173.128.15:80->128.176.154.30:3827128.176.154.30:62222
httpd5    11692     http    1u  inet   0x93d12500        0x0    TCP 163.173.128.15:80->128.176.154.30:3827128.176.154.30:62222
httpd5    11692     http    2u  inet   0x93d12500        0x0    TCP 163.173.128.15:80->128.176.154.30:3827128.176.154.30:62222
httpd5    11895     http    0u  inet   0x93bc6000        0x0    TCP 163.173.128.15:80->158.152.31.209:1937158.152.31.209:37127
httpd5    11895     http    1u  inet   0x93bc6000        0x0    TCP 163.173.128.15:80->158.152.31.209:1937158.152.31.209:37127
httpd5    11895     http    2u  inet   0x93bc6000        0x0    TCP 163.173.128.15:80->158.152.31.209:1937158.152.31.209:37127
httpd5    11974     http    0u  inet   0x93bd5400        0x0    TCP 163.173.128.15:80->199.0.74.97:4940199.0.74.97:19475
httpd5    11974     http    1u  inet   0x93bd5400        0x0    TCP 163.173.128.15:80->199.0.74.97:4940199.0.74.97:19475
httpd5    11974     http    2u  inet   0x93bd5400        0x0    TCP 163.173.128.15:80->199.0.74.97:4940199.0.74.97:19475
httpd5    11982     http    0u  inet   0x93c25c00        0x0    TCP 163.173.128.15:80->193.212.200.25:2654193.212.200.25:24074
httpd5    11982     http    1u  inet   0x93c25c00        0x0    TCP 163.173.128.15:80->193.212.200.25:2654193.212.200.25:24074
httpd5    11982     http    2u  inet   0x93c25c00        0x0    TCP 163.173.128.15:80->193.212.200.25:2654193.212.200.25:24074
httpd5    11986     http    0u  inet   0x93c78a00        0x0    TCP 163.173.128.15:80->128.8.147.97:1048128.8.147.97:6148
httpd5    11986     http    1u  inet   0x93c78a00        0x0    TCP 163.173.128.15:80->128.8.147.97:1048128.8.147.97:6148
httpd5    11986     http    2u  inet   0x93c78a00        0x0    TCP 163.173.128.15:80->128.8.147.97:1048128.8.147.97:6148
httpd5    12144     http    0u  inet   0x93d12600        0x0    TCP 163.173.128.15:80->193.174.167.3:3662193.174.167.3:19982
httpd5    12144     http    1u  inet   0x93d12600        0x0    TCP 163.173.128.15:80->193.174.167.3:3662193.174.167.3:19982
httpd5    12144     http    2u  inet   0x93d12600        0x0    TCP 163.173.128.15:80->193.174.167.3:3662193.174.167.3:19982
httpd5    12292     http    0u  inet   0x93bf1b00        0x0    TCP 163.173.128.15:80->136.200.162.106:3643136.200.162.106:15118
httpd5    12292     http    1u  inet   0x93bf1b00        0x0    TCP 163.173.128.15:80->136.200.162.106:3643136.200.162.106:15118
httpd5    12292     http    2u  inet   0x93bf1b00        0x0    TCP 163.173.128.15:80->136.200.162.106:3643136.200.162.106:15118
httpd5    12296     http    0u  inet   0x93c70500        0x0    TCP 163.173.128.15:80->138.172.19.101:1045138.172.19.101:5380
httpd5    12296     http    1u  inet   0x93c70500        0x0    TCP 163.173.128.15:80->138.172.19.101:1045138.172.19.101:5380
httpd5    12296     http    2u  inet   0x93c70500        0x0    TCP 163.173.128.15:80->138.172.19.101:1045138.172.19.101:5380
httpd5    12386     http    0u  inet   0x93c79800        0x0    TCP 163.173.128.15:80->144.58.85.92:1698144.58.85.92:41478
httpd5    12386     http    1u  inet   0x93c79800        0x0    TCP 163.173.128.15:80->144.58.85.92:1698144.58.85.92:41478
httpd5    12386     http    2u  inet   0x93c79800        0x0    TCP 163.173.128.15:80->144.58.85.92:1698144.58.85.92:41478
httpd5    12408     http    0u  inet   0x93ce4000        0x0    TCP 163.173.128.15:80->134.129.117.30:1049134.129.117.30:6404
httpd5    12408     http    1u  inet   0x93ce4000        0x0    TCP 163.173.128.15:80->134.129.117.30:1049134.129.117.30:6404
httpd5    12408     http    2u  inet   0x93ce4000        0x0    TCP 163.173.128.15:80->134.129.117.30:1049134.129.117.30:6404
httpd5    12421     http    0u  inet   0x93d4ca00        0x0    TCP 163.173.128.15:80->129.13.113.98:3683129.13.113.98:25358
httpd5    12421     http    1u  inet   0x93d4ca00        0x0    TCP 163.173.128.15:80->129.13.113.98:3683129.13.113.98:25358
httpd5    12421     http    2u  inet   0x93d4ca00        0x0    TCP 163.173.128.15:80->129.13.113.98:3683129.13.113.98:25358
httpd5    12428     http    0u  inet   0x93d08b00        0x0    TCP 163.173.128.15:80->129.55.20.2:3597129.55.20.2:3342
httpd5    12428     http    1u  inet   0x93d08b00        0x0    TCP 163.173.128.15:80->129.55.20.2:3597129.55.20.2:3342
httpd5    12428     http    2u  inet   0x93d08b00        0x0    TCP 163.173.128.15:80->129.55.20.2:3597129.55.20.2:3342
httpd5    12438     http    0u  inet   0x93bd7000        0x0    TCP 163.173.128.15:80->131.169.30.39:5102131.169.30.39:60947
httpd5    12438     http    1u  inet   0x93bd7000        0x0    TCP 163.173.128.15:80->131.169.30.39:5102131.169.30.39:60947
httpd5    12438     http    2u  inet   0x93bd7000        0x0    TCP 163.173.128.15:80->131.169.30.39:5102131.169.30.39:60947
httpd5    12444     http    0u  inet   0x93ce4f00        0x0    TCP 163.173.128.15:80->192.93.219.4:4209192.93.219.4:28944
httpd5    12444     http    1u  inet   0x93ce4f00        0x0    TCP 163.173.128.15:80->192.93.219.4:4209192.93.219.4:28944
httpd5    12444     http    2u  inet   0x93ce4f00        0x0    TCP 163.173.128.15:80->192.93.219.4:4209192.93.219.4:28944
httpd5    12489     http    0u  inet   0x93c7da00        0x0    TCP 163.173.128.15:80->192.20.239.133:1097192.20.239.133:18692
httpd5    12489     http    1u  inet   0x93c7da00        0x0    TCP 163.173.128.15:80->192.20.239.133:1097192.20.239.133:18692
httpd5    12489     http    2u  inet   0x93c7da00        0x0    TCP 163.173.128.15:80->192.20.239.133:1097192.20.239.133:18692
httpd5    12493     http    0u  inet   0x93d09e00        0x0    TCP 163.173.128.15:80->128.194.71.200:1541128.194.71.200:1286
httpd5    12493     http    1u  inet   0x93d09e00        0x0    TCP 163.173.128.15:80->128.194.71.200:1541128.194.71.200:1286
httpd5    12493     http    2u  inet   0x93d09e00        0x0    TCP 163.173.128.15:80->128.194.71.200:1541128.194.71.200:1286
httpd5    12499     http    0u  inet   0x93c7d400        0x0    TCP 163.173.128.15:80->163.173.129.0:2097163.173.129.0:12552
httpd5    12499     http    1u  inet   0x93c7d400        0x0    TCP 163.173.128.15:80->163.173.129.0:2097163.173.129.0:12552
httpd5    12499     http    2u  inet   0x93c7d400        0x0    TCP 163.173.128.15:80->163.173.129.0:2097163.173.129.0:12552
httpd5    12507     http    0u  inet   0x93ca7300        0x0    TCP 163.173.128.15:80->163.167.95.41:1553163.167.95.41:4358
httpd5    12507     http    1u  inet   0x93ca7300        0x0    TCP 163.173.128.15:80->163.167.95.41:1553163.167.95.41:4358
httpd5    12507     http    2u  inet   0x93ca7300        0x0    TCP 163.173.128.15:80->163.167.95.41:1553163.167.95.41:4358
httpd5    12508     http    0u  inet   0x93c22f00        0x0    TCP 163.173.128.15:80->160.9.128.12:1025160.9.128.12:260
httpd5    12508     http    1u  inet   0x93c22f00        0x0    TCP 163.173.128.15:80->160.9.128.12:1025160.9.128.12:260
httpd5    12508     http    2u  inet   0x93c22f00        0x0    TCP 163.173.128.15:80->160.9.128.12:1025160.9.128.12:260
httpd5    12509     http    0u  inet   0x93d4de00        0x0    TCP 163.173.128.15:80->129.13.59.52:4453129.13.59.52:25873
httpd5    12509     http    1u  inet   0x93d4de00        0x0    TCP 163.173.128.15:80->129.13.59.52:4453129.13.59.52:25873
httpd5    12509     http    2u  inet   0x93d4de00        0x0    TCP 163.173.128.15:80->129.13.59.52:4453129.13.59.52:25873
httpd5    12529     http    0u  inet   0x93c79000        0x0    TCP 163.173.128.15:80->128.42.76.12:1074128.42.76.12:12804
httpd5    12529     http    1u  inet   0x93c79000        0x0    TCP 163.173.128.15:80->128.42.76.12:1074128.42.76.12:12804
httpd5    12529     http    2u  inet   0x93c79000        0x0    TCP 163.173.128.15:80->128.42.76.12:1074128.42.76.12:12804
httpd5    12533     http    0u  inet   0x93ca7800        0x0    TCP 163.173.128.15:80->142.92.183.101:1038142.92.183.101:3588
httpd5    12533     http    1u  inet   0x93ca7800        0x0    TCP 163.173.128.15:80->142.92.183.101:1038142.92.183.101:3588
httpd5    12533     http    2u  inet   0x93ca7800        0x0    TCP 163.173.128.15:80->142.92.183.101:1038142.92.183.101:3588

The load is quite low:

web-server> uptime
16:37  up 39 mins,  3 users,  load average: 1.04, 1.12, 1.11
web-server> ps aux | head
USER       PID %CPU %MEM   VSZ  RSS TT  S    STARTED         TIME COMMAND
foobar   13523 80.0  0.3 1.76M 400K p2  R  + 16:33:45     2:29.44 totalseq.axp
root         0  2.0 55.3  498M  70M ??  R <  15:58:42    30:34.87 [kernel idle]
root      1440  1.0  0.1 2.59M 120K ??  S    16:00:17     0:25.73 @ http daemon 80
http     14593  0.0  0.2 2.63M 256K ??  S    16:36:39     0:00.02 @130.218.5.230 send 1 /delete/tmp
http     14601  0.0  0.1 2.59M 184K ??  S    16:36:40     0:00.01 @a2-eth.ph.man.ac.uk gcmdl
http     14584  0.0  0.1 2.59M 192K ??  S    16:36:38     0:00.01 @foppa.rice.edu gcmdl
http     14573  0.0  0.2 2.63M 240K ??  S    16:36:36     0:00.01 @huolto.rotko.rotol.fi send 1 /Im
http     14587  0.0  0.1 2.59M 192K ??  S    16:36:38     0:00.01 @156.98.66.40 gcmdl
root       117  0.0  0.0 1.34M  32K ??  I    15:59:28     0:00.02 /usr/sbin/binlogd

Configuration: DEC 3000/600S with 128 Mb RAM, OSF/1 2.0. The HTTP 
server is a local one (software written here).

So, if any one knows how to deal with this situation or where to look...

E-mail or post, I'll summary,

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
bortzmeyer@cnam.fr            Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

http://web.cnam.fr/personnes/bortzmeyer/home_page.dom

					
	



-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 23:01:08 -0500
From:      phil@zeus.fasttax.com (Phil Howard)
To:        comp.protocols.tcp-ip
Subject:   Re: Bad Class C Addr?

clements@phoenix.cs.uga.edu (Brian Clements) writes:

>The IP address they obtained was 204.29.255.0.   Can anyone see a 
>possible problem this this IP?  SGI's system manager pgm does not
>want to let me add this IP address into the system.


kh@world.std.com (Kurt Hackenberg) replies:

...

>Most likely the program is checking whether each byte is zero or all
>ones, which is not the right test.  What it should do, to check the
>network field of a class C address, is something like
>
>	if ((adr & 0x1fffff) == 0 || (adr & 0x1fffff) == 0x1fffff)
>		fail();
>
>I'd say you have done the right thing by bypassing this program and
>using the network number.  You might want to report the bug to SGI.


That'll teach you to try using those "friendly" interfaces.  I would
guess that SGI probably gave the project to some programmer fresh out
of college who had more windowing skills and few (if any) networking
skills.  Sounds like his perception was strictly class B.  Most large
schools have class B networks, so this is not surprising.
-- 
Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
CLR/Fast-Tax            | utility?
phil@fasttax.com        |

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 15:22:05 GMT
From:      tclogras@artsci.wustl.edu (Timothy Charles Lo Grasso )
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP software for IBM's?

Timothy Charles Lo Grasso (tcg1@cec1.wustl.edu) wrote:
: 	I am looking for some good shareware BootP software that will run on an
: IBM compatable 386 machine with an EtherExpress Ethernet card installed.  I
: would like to be able to allocate IP addresses using the user's ethernet
: address.  Please, Please send any and all information you have to
: tcg1@cec.wustl.edu.  Many thanks.

It seems my site will be down for the next couple of days, so I will keep 
checking here for any answers to this question.  Hope there is an answer!



: --
: Tim Lograsso @ Washington University, St. Louis Mo
: tcg1@cec.wustl.edu


-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 15:40:42 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.os.386bsd.questions,comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: Problems with FreeBSD SLIP (can telnet/cannot ping)

In article <1994Aug1.055730.4188@atlas.com>, brantk@adcmail.atlas.com (brantk) writes:
|> 
|> I'm working on adding my small network to the Internet.  Connection is
|> made via a 14.4Kbps dialup SLIP connection.  I can telnet out, ftp,
|> you name it.  I just can't ping hosts outside of my own local network.
|> Strange, considering I can reach them via telnet.
|> 
|> Here's a few facts to consider:
|> 
|> * The IP address of my local net is 199.26.157.x, which is an "official"
|> class C assigned by the InterNIC.
|> 
|> * My domain is vertigo.com, this is NOT official, and is not used outside
|> my local network (not until it's official, anyways).
|> 
|> * I am connecting to my provider's NetBlazer, which uses Dynamic IP. (I
|> get a different IP address every time I dial up).
|> 
|> * My gateway machine is an Intel-based machine running FreeBSD 1.1.0(Beta).
|> All of my tests were run from the gateway (everest).
|> 
|> * Configuration and routing are done as follows:
|> 	slattach -s 38400 /dev/ttyd0
|> 	ifconfig sl0 ${IP_ADDRESS} up
|> 	route flush
|> 	route add default ${IP_ADDRESS}
|>  
|> Any ideas on where I should continue looking?  I can't find anything
|> abnormal in any of my configuration files.

They probably have ICMPs turned off on your line.  This is a common
thing to do to avoid wasting bandwidth on them.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 15:46:50 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection establishment

In article <1994Aug1.115848.19318@athen.mch.sni.de>, egn@athen.mch.sni.de (Emil Naepflein) writes:
|> 
|> I need help from a TCP expert. The problem is, that sometimes the
|> ACK during connection establishment is lost. After that the client side
|> is hanging in ESTABLISHED state, the server side has closed the conntection.
|> I don't find any information about this problem in the TCP RFC and in
|> Richard Stevens book. May be there is someone which can help me.
|> 
|> 
|> Here is a simple description of the problem:
|> 
|> SERVER					CLIENT
|> 					send SYN
|> send SYN,ACK
|> 					send ACK (this ACK is lost)
|> send SYN,ACK
|> 					no answer from client
|> send SYN,ACK
|> 					no answer from client
|> server closes connection without sending RST
|> 					client stayes in ESTABLISHED
|> 
|> 
|> Here are some questions I need an answer for:
|> 
|> 1. Should the client send an ACK after receiving SYN,ACK in ESTABLISHED state?

Yes, since the sequence number on the server's SYN,ACK packet should
show that the server has not seen the client's ACK.

|> 2. Should the client send a RST after receiving SYN,ACK in ESTABLISHED state?

No, as long as the SYN is "legal."  It's legal to have a SYN in the
packet only when sequence number == initial sequence number.  Otherwise,
it's best to destroy the socket on the assumption that the other guy is
seriously confused.

|> 3. Should the server really do the retransmits?

Yes.  The retransmit is done to prod the other end into transmitting
either an ACK (if it was lost) or a RST (if the connection has
disappeared.

|> 4. Should the server send a RST after the retransmits?

Yes.  Once it gets annoyed with the other side, it should discard the
socket and destroy the connection with a RST.  The client is also in
error at this point, since the RST should cause an immediate transition
from ESTABLISHED to CLOSED state.

|> 5. What is the behaviour of other TCP implementations in this situation?

BSD 4.3 will resend the ACK, and will drop sockets on receipt of RST.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      01 Aug 1994 17:57:15 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Receiver for pktdrv in C or asm

In article <897@enstb.enst-bretagne.fr> friant@rsm.enst-bretagne.fr writes:

   I would like to have informations about the programming of a packet
   driver receive routine (C or assembler). I work on PC and I use SMC
   cards. I have problems with the use of access_type function that
   normally initiates access to packets by calling twice the receiver
   routine.

Look for seepkt.c and pktdrvr.[ch] in the Crynwr packet driver
collection.

--
-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 1994 19:42:26 GMT
From:      acsgen@garnet.msen.com (Applied Computer Solutions)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: PCBridge as link to SLIP/PPP provider WON'T WORK

Thanks for your replies.  To me, what the first poster, Laine Stump,
describes as a bridge, sounds more like a repeater to me.

I know that bridges between EtherNet and Token Ring, and EtherNet and
broadband exist, so it makes sense to me that a bridge between EtherNet
and SLIP could exist.  My concern being that SLIP might not be a true
"data link" protocol, and, therefore, couldn't be plugged into a bridge.

The information that a host or router need not be aware of the presense
of another router between it and the host it is sending messages to
does renew my interest in trying PCroute (I have downloaded the docs,
and they say that RIP can be turned off).  Routing would allow me to
consider addtional hosts on my ethernet without having to worry about
dumping excess trafic over the SLIP link.

Are ther any IP addresses that are considered "null" - for example,
every SunOS system I've installed has 192.9.200 as its default net
number.

Thanks in advance.

Ron Wilson, rwilson@vsa.com

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 1994 20:49:23 GMT
From:      sterrett@manta.nosc.mil (Anthony E. Sterrett)
To:        comp.protocols.tcp-ip
Subject:   How does Sun/Solaris handle the Source Quech Message?


	In general how does the Sun/Solaris OS handle a Source Quech Message
	from the router?
	Thanks in Advance.
	Tony

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 1994 21:01:28 GMT
From:      shark@netcom.com (Stefan Sharkansky)
To:        comp.protocols.tcp-ip
Subject:   Re: Determination of server port from client's side??

In article <1994Aug1.085753.5413@inland.com> bruss@inland.com (Trevor Bruss) writes:
>   I'm trying to find out if there is a way to determine which port my server
>is running on from another platform.  Let me clarify:
>   I'm trying to communicate from a VAX (Multinet) client to a SUN (whatever
>version TCP/IP) server.  I'm using sockets to make the connection.  I've set
>the server's port to 0 which from what I understand polls for an open port.  I
>want the client to be able to determine which port to use but I don't know how. 
>I haven't run across anything in the Multinet manual so I was hoping someone
>here could help me.


You need to have some kind of "offline" agreement between client and server
as to which port to contact the server on.  Two common strategies
are:

1) Use of well-known ports. i.e. the server for a given service will always
use the same port (for example, the finger service always uses port 79).
The well-known ports are best reserved through the Internet Assigned
Numbers Authority (IANA), and are normally maintained locally on the NIS
services map.  (of course it's not always necessary to register with the
IANA if you have complete control over the environment where the
application will be used).  For purposes of testing, it's also a good
idea to be able to explicitly specify port numbers to both client and
server on the respective command lines.

2) If the server chooses to pick a random port each time, the server would
have to advertise its port through some other entity. e.g. a "portmapper"
server that knows the real server's port, and sits on its own well-known
port to respond to queries from the real server's client. (this is how
SunRPC works).  I'm not aware of any standard general purpose mechanism for
doing this, so you would probably have to write some original code.

Most people choose to do (1).

--

Stefan Sharkansky
Prospero Systems Research, Inc.
USMAIL	520 Frederick St. Box 19, San Francisco, CA 94117
VOICE	(415) 731-8114		FAX  (415) 731-3395
E-MAIL	shark@netcom.COM

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue,  2 Aug 1994 10:24:36 -0800
From:      larry.witherspoon@mccaw.com (larry witherspoon)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Problems negotiating telnet sessions

I have a Larse Access T csu/dsu that is connected to our network.  We have 
the console port of the Access T connected to a xyplex terminal server port.  
We have setup a rotarty ip address on the terminal server to allow users in 
the network to telnet to the ip address and configure the ACCESS T csu/dsu.  
This all works fine until we enable password control on the ACCESS T.

Problem:  When I connect to the ip address from a Sun workstation, it will 
not accept the password.  The only way to make it work is toggle to telnet 
command mode ; then change to line mode.  I can enter the password then and 
the ACCESS T allows me in but keys do not work.  I then must toggle to telnet 
command mode and change to character mode.  This only happens with the Sun 
workstation.  I can telnet from a Macintosh running TCP Connet II or 
Reflecteion Emulation software packages and it works fine.

It looks like the Larse Access T, Xyplex Terminal Server and Sun Work station 
are not doing all of the proper negotiations to set proper terminal type and 
access mode.  I am trying to get a sniffer trace of the Mac and Sun 
workstations to see where the negotiations are not working.  Maybe someone 
has had this challenge before.

Question:  Does anyone know or have a method to make the three devices 
connect automatically with out the manual changing of mode??

The Sun workstations are used to monitor and trouble shoot the network and we 
login to the consoles regularly and it is a very annoying problem.  If anyone 
has any ideas it would be appreciated.  

Thanks,
Joe M. Williamson


Respond to 

joe.williamson@mccaw.com    Thanks Again.





-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 94 21:18:00 GMT
From:      byrne.ghavalas@digitec.co.za (Byrne Ghavalas)
To:        comp.protocols.tcp-ip
Subject:   TCP / IP

Hi All,

Recently, I joined a company, which has installed a WAN.  They have
recently upgraded to 64kb lines between regions.  Apparently, they will
be using the TCP / IP protocol.

I know absoloutley nothing about it, and was wondering if you chaps
might be able to educate me.  Perhaps there is some literature
available?

Thanks
Byrne G.
---
. TLX v4.00 . A hole is nothing but you can still break your neck in it
___ Blue Wave/QWK v2.12

----
--- Digitec Online --- Johannesburg, South Africa --- tel +27 11 476-2008 ---
--- You can TELNET Africa's biggest and most popular BBS on 196.11.62.106 ---

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 1994 21:29:52 GMT
From:      atlnafl@zeus.datasrv.co.il (Naftaly Lerman)
To:        comp.protocols.tcp-ip
Subject:   IP-routing using RAW sockets

I need to develop a package that provides access to all IP-packets
arriving/leaving a host on the network. This mechanism is to be used as
part of a higher level facility that will support tunneling of IP-packets
through radio and other non-tcpip networks.

I thought/understood that the way that this can be performed (i.e.
interception of IP traffic into/out of a host) is using RAW sockets
(SOCK_RAW BSD socket type). However, I discovered that it only provides
me with access to IP packets leaving the host.

Can anyone suggest how I can access all IP traffic both entering and
leaving a host using the standard BSD socket interface services?

Thanks

atlnafl@zeus.datasrv.co.il


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 1994 21:55:48 GMT
From:      doug@eng.auburn.edu (Doug Hughes)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   FDDI vs. 4 ethernets


  We've come to a situation which I could only call not envious.
Currently we have four ethernets with servers serving a large
number of sunsets.  We have the option of going to a switched FDDI
topology. However, if we do, we have to give at least 3 of the four
ethernets back.
  I have had several apocryphal stories about people switching to
FDDI and only getting roughly 2 times the throughput over a normal
ethernet.  Are traffic load is largely NFS, with a significant
amount of NIS+ thrown in.  Has anybody out there used a FDDI
switch? How have the results been in terms of ethernet bandwidth?
Would you recommend it as a possible trade for 4 ethernets?  We
have no hard data, just propaganda and stories upon which to make
conclusions and were hoping for some insight from anybody who has
been there before.

-- 
____________________________________________________________________________
Doug Hughes					Engineering Network Services
System/Net Admin  				Auburn University
			doug@eng.auburn.edu
"The Light at the end of the tunnel is the headlamp of an oncoming train"

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Aug 1994 23:47:05 GMT
From:      marcbg@netcom.com (Marc B. Grant)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin
Subject:   Help! Disabling Shell Access from Telnet

What setup do I need to use to disable the subsehll access from the 
telnet> prompt when someone is on my system?  The user is logged on from 
a captive account, and is automatically connected to a remote host.  
However, if he enters the escape sequence and reaches teh telnet prompt, 
then enteres the "!" for the subshell command, he has access to the 
operating system.  IS there anyway of locking this out?

Thanks in advance!!

-- 
 Marc Grant                                          
 Home: marcbg@netcom.com                             Telephone: 214-205-4593
 Office: marcbg@esy.com                                  Amateur Radio N5MEI
              "The road to enlightment is chuck full o' potholes"

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 00:03:07 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <sej.775313310@interaccess> sej@psycfrnd.interaccess.com (Stephen Johnson) writes:
>I have not had good luck running Novell servers as routers with
>different subnet masks on different interfaces.

First of all, I assume you mean different subnet masks *for different
subnets of the same network*. This is mainly a limitation of RIP,
since it doesn't convey the subnet mask. The NetWare TCP/IP code has
actually supported variable subnet masks, to a greater or lesser
degree over time, but it's not something the manuals have admitted.
Without the support of the routing protocol, variable subnets are
inherent complicated and dangerous.

Recent releases explicitly support variable subnet masks via Proxy
ARP. Of course when it comes out, the release with routing protocols
such as RIP-II and OSPF which themselves support variable sized
subnets will remove this restriction entirely. Last I heard, though,
RIP-II and OSPF will not be packaged with NetWare but will only be
available in the MultiProtocol Router add-on product.

					don provan
					donp@novell.com

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 00:23:33 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection establishment

In article <1AUG199412240151@hearts.aces.com> gavron@ACES.COM writes:
>In article <1994Aug1.115848.19318@athen.mch.sni.de>, Emil.Naepflein@mch.sni.de (Emil Naepflein) writes...
>#Here is a simple description of the problem:
>#SERVER					CLIENT
>#					send SYN
>#send SYN,ACK
>#					send ACK (this ACK is lost)
>#send SYN,ACK
>#					no answer from client
>#send SYN,ACK
>#					no answer from client
>#server closes connection without sending RST
>#					client stayes in ESTABLISHED
>#...
>#4. Should the server send a RST after the retransmits?
>
>Well what we're seeing is not covered in the protocol state machine.
>The server is in SYN RCVD from which it can CLOSE/snd FIN or rcv ACK.
>If it chooses to "eliminate" the socket then it should send an RST, 
>but that's not covered in 793.
>
>In fact, I'd venture that doing this is a violation of 793.

I doubt it. I mean, look at the situtation: the server is aborting the
connection because its packets are not being acknowledged. Under
normal conditions, this could only happen because there is no longer a
communications link between the two nodes. It would be somewhat silly
to send a RST to the destination that you've just concluded isn't
hearing your packets. The fact that the actual scenario involves a
pathalogical problem in the client is no reason to take the server to
task for jumping to the obvious conclusion that a RST packet was no
more likely to arrive than the previous N retransmissions.

I wouldn't mind a RST packet, but I can't fault the server
implementation for not sending one.

						don provan
						donp@novell.com

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 00:23:45 GMT
From:      jeremy_gorman@smtp.esl.com (Jeremy Gorman)
To:        comp.protocols.tcp-ip
Subject:   Port-number Server Implementations??

Hello,

Is anyone aware of a server implementation providing dynamic port
allocation for sockets (both TCP/IP and UDP/IP) as described below. I would
be interested in same if PD or of moderate cost commercially.

We have an environment where many distinct applications are being
dynamically created and destroyed in a distributed system -- each
application may be comprised of several socket-communicating processes
often residing at distinct IP addresses.

In the interest of allowing developers to focus on their own application
(without excessive concern for whether the port they chose to bind their
socket to conflicts with someone else's #define) it might be convenient to
have a port server. When their process "a" at IP address "A" wants to
connect to their process "b" at IP address "B", why worry about port
numbers at compile time??

Maybe process "a" wants a *few* socket connections (maybe two TCP and one
UDP) to process "b". If each connection has 1) a unique connection NAME and
2) both "a" and "b" know this NAME and 3) "a" knows it must
bind()/listen()/accept() and "b" knows it must connect(), then each could
connect to a local server which will provide them with a common port
number. The servers must talk to each other (at some preordained port
number #define PS_PORT? -- they already have the IP addresses).

An additional advantage:
Running my process "a" code on a different processor (say "C") than the one
with IP address "A" can be accomplished if "b" knows only the new IP
address and without regard for who else's processes may be using ports on
"C". 

I started writing this up as follows:

--------
A Port Server (PS) process will be spawned at system startup on every
processor which handles an IP interface in the system. In the interest of
system resource conservation, the PS must remain blocked on a socket at all
times when not actively assigning, freeing, or providing information about
its ports to client tasks. Each PS must (as is typical for a  server
process) be prepared to accept() connections on a predefined unique port,
probably #defined as PS_PORT.

The PS must maintain a table of connection names and the corresponding
ports assigned to each locally bound connection. The port numbers assigned
by the PS could be allocated from a pool of consecutive port numbers which
could, by convention, be the same on all IP connected devices in the
system. 

When a client connects to a PS with a port-num-request message for a
dynamically assigned port number, the client must provide three parameters:
1) the connection name; 2) a "bind" flag indicating true if the IP
connection is to be bound to a port at this IP address or false if it is to
be bound at the other end of the connection; and 3) the IP address of the
other end of the connection. If the bind flag is true, the server selects a
free port number, and makes an entry in its table associating this port
number with the name received, and then replies to the client with a
message indicating this port number. If the bind flag is false, the PS
connect()'s  to the address of parameter 3 and port PS_PORT. If this
connect() call fails it must sleep for a while, then try again. When it
does successfully connect to the other PS at the foreign IP address, it
sends a name-info-request message with the name it received from its own
client. The foreign server responds with the port it assigned to its own
locally binding client. Slightly more sophisticated deadlock avoidance must
be implemented than described in this paragraph, along with handling
number_of_connections arguments to listen() and server process forking if
listen() allows multiple concurrent clients.

When a task completes the communication necessary on a xxP/IP socket
connection with a dynamically assigned port, it must free the port by
sending a port-free message to the PS.

--------

Any info would be appreciated, including a better choice of groups to post
to.
(I already tried comp.unix.questions)

Please reply via email if convenient.

Thanks in advance.

-- 
Jeremy Gorman(jeremy_gorman@smtp.esl.com)
Sr. Software Engineer
Advanced Technology Directorate
ESL (a TRW Company)
The above are my *own* opinions and do not reflect etc...

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 00:24:55 GMT
From:      manuel@crt0.crt.umontreal.ca (Jose Manuel Pires 514-340-6046)
To:        comp.protocols.tcp-ip
Subject:   Requesting info about "ping protocols"


Hi,

I'm a newbie in the field of RPC and I would need to implement what you guys
call a ping protocol to maintain a list of active (alive) clients and their
status (BUSY, IDLE, etc.)  The server would maintain this list.

If there's a FAQ for this group please let me know.  And if there isn't one, a
list of books would be very much appreciated.  Thanks!

JMP

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 00:37:56 GMT
From:      phil@rivendell.apana.org.au (Phil Homewood)
To:        comp.os.386bsd.questions,comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: Problems with FreeBSD SLIP (can telnet/cannot ping)

brantk (brantk@adcmail.atlas.com) wrote:

: I'm working on adding my small network to the Internet.  Connection is
: made via a 14.4Kbps dialup SLIP connection.  I can telnet out, ftp,
: you name it.  I just can't ping hosts outside of my own local network.
: Strange, considering I can reach them via telnet.

Perhaps the other end of your SLIP link has been set to
throw away ICMP packets  (ala FreeBSD slattach's -n option).
Try a traceroute, see what it does.  If it fails at your SLIP
site,  and you _really_ need to be able to ping the outside
world, go ask your service provider if they'd mind enabling
ICMP packets down the link.

Cheers,

Phil.
--
Phil Homewood                           phil@rivendell.apana.org.au
APANA Brisbane Regional Co-Ordinator    brisbane@apana.org.au

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 11:12:20 -0500
From:      flipper@pentagon.io.com (Peter Sierant)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

>
>The router-requirements document says:
>
> 58         The bit positions containing this extended network number are
> 59         indicated by a 32-bit mask called the "subnet mask"; it is
> 60         recommended but not required that the <Subnet-number> bits be
> 61         contiguous and fall between the <Network-number> and the
> 62         <Host-number> fields.  No subnet should be assigned the value
> 63         zero or -1 (all one bits).
>

" No subnet SHOULD be assigned . . ."  Why not?  I realize the reasons 
why the net or host portion can't be zero or -1, but why the subnet? The 
rfc (950) is even a bit vague, stating SHOULD as opposed to MUST and 
citing convention as the reason.  

The reason I care is that various manufacturers either support or don't 
support, let's say,  1 bit subnets.  One the other hand, many 
manufacturers don't support non-contiginous bits, which is clearly a 
bug. There doesn't really seem to be a consensus.  I concerned that using
a 2 bit mask on a class C address (255.255.255.192) causes you to lose 
over half of your addresses.  Using a 3 bit mask, you still lose over 60 
addresses, and are limited to only 30 nodes per segment. It's not like IP 
addresses are unlimited.

Anyone know?

Thanks,
-- 
--Pete                                        Ugly box of mostly Microsoft 
flipper@io.com           
jblues@wintermute.tci.com                            
psierant@klaven.tci.com                                 ECNE  Linux  OS/2

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 03:00:16 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: PCBridge as link to SLIP/PPP provider

: I've got an old Unix box that has ethernet, but I am unable to find
: a SLIP (let alone PPP) driver for.  While I can run an old version
: of KA9Q on it (newer version won't compile as is and I don't have the
: time or energy to hack on the sources), what I really want to do is
: use the "built in" TCP/IP services.

If you have some old 386 or 486 machine handy, with a modest amount
of disk space available, you could run Linux on it.  That would 
get around the problem of having to hack on DOS based systems
as well as give you a place to relay mail through.

(That's what I would do, anyway, if your goal is to be Internet ready
without going out and getting a budget for operating system software
approved.  There are other choices if you do want to spend more money.)

--Ed

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 15:40:09 -0700
From:      jantypas@ccnet.com (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   What are "sider" IP numbers?

Recently, while shopping for an IP provider for a client, a vendor
noted that the use of "sider" IP numbers was better because of the
crunch on address space.

I've never heard this term before.  What is a 
"sider" number?  I assume it means a subnet of a class C address?
-- 
John Antypas@21st Century Softwware (jantypas@soft21.s21.com)

"God is too busy to create chaos and disorder in this world, he can't be
 everywhere at once all of the time,  That's why he made two year olds"
 "

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 04:05:37 GMT
From:      libes@nist.gov (Don Libes)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Help! Disabling Shell Access from Telnet

In article <marcbgCtvrEH.HGo@netcom.com> marcbg@netcom.com (Marc B. Grant) writes:
   What setup do I need to use to disable the subsehll access from the 
   telnet> prompt when someone is on my system?  The user is logged on from 
   a captive account, and is automatically connected to a remote host.  
   However, if he enters the escape sequence and reaches teh telnet prompt, 
   then enteres the "!" for the subshell command, he has access to the 
   operating system.  IS there anyway of locking this out?

The following script runs telnet but prevents telnet's escape
character from getting to the telnet program.

	#!/usr/local/bin/expect --
	spawn telnet host
	interact "\x1d" {}

Don

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 94 06:53:51 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Determination of server port from client's side??

In article <sharkCtvJqG.J6G@netcom.com> shark@netcom.com (Stefan Sharkansky) writes:
>In article <1994Aug1.085753.5413@inland.com> bruss@inland.com (Trevor Bruss) writes:
>>   I'm trying to find out if there is a way to determine which port my server
>>is running on from another platform.  Let me clarify:
>>   I'm trying to communicate from a VAX (Multinet) client to a SUN (whatever
>>version TCP/IP) server.  I'm using sockets to make the connection.  I've set
>>the server's port to 0 which from what I understand polls for an open port.  I
>>want the client to be able to determine which port to use but I don't know how. 
>>I haven't run across anything in the Multinet manual so I was hoping someone
>>here could help me.
>
>
>You need to have some kind of "offline" agreement between client and server
>as to which port to contact the server on.  Two common strategies
>are:
>
>1) Use of well-known ports. i.e. the server for a given service will always
>use the same port (for example, the finger service always uses port 79).
>The well-known ports are best reserved through the Internet Assigned
>Numbers Authority (IANA), and are normally maintained locally on the NIS
>services map.  (of course it's not always necessary to register with the
>IANA if you have complete control over the environment where the
>application will be used).  For purposes of testing, it's also a good
>idea to be able to explicitly specify port numbers to both client and
>server on the respective command lines.
>
>2) If the server chooses to pick a random port each time, the server would
>have to advertise its port through some other entity. e.g. a "portmapper"
>server that knows the real server's port, and sits on its own well-known
>port to respond to queries from the real server's client. (this is how
>SunRPC works).  I'm not aware of any standard general purpose mechanism for
>doing this, so you would probably have to write some original code.
>
>Most people choose to do (1).
>

How about:

3) Use TCP MUX (port 1)


-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 94 07:03:36 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection establishment

In article <1994Aug2.002333.19123@novell.com> donp@novell.com (don provan) writes:
>In article <1AUG199412240151@hearts.aces.com> gavron@ACES.COM writes:
>>In article <1994Aug1.115848.19318@athen.mch.sni.de>, Emil.Naepflein@mch.sni.de (Emil Naepflein) writes...
>>#Here is a simple description of the problem:
>>#SERVER					CLIENT
>>#					send SYN
>>#send SYN,ACK
>>#					send ACK (this ACK is lost)
>>#send SYN,ACK
>>#					no answer from client
>>#send SYN,ACK
>>#					no answer from client
>>#server closes connection without sending RST
>>#					client stayes in ESTABLISHED
>>#...
>>#4. Should the server send a RST after the retransmits?
>>
>>Well what we're seeing is not covered in the protocol state machine.
>>The server is in SYN RCVD from which it can CLOSE/snd FIN or rcv ACK.
>>If it chooses to "eliminate" the socket then it should send an RST, 
>>but that's not covered in 793.
>>
>>In fact, I'd venture that doing this is a violation of 793.
>
>I doubt it. I mean, look at the situtation: the server is aborting the
>connection because its packets are not being acknowledged. Under
>normal conditions, this could only happen because there is no longer a
>communications link between the two nodes. It would be somewhat silly
>to send a RST to the destination that you've just concluded isn't
>hearing your packets. The fact that the actual scenario involves a

Uh, there is _NO_ way to know for sure that the destination is not 
hearing your packets. So you are not getting ACKs, either the other side 
is getting nothing to ACK, or _you are not receiving the ACKs sent to you_. 
(or the other side is confused and just not able to/not trying to ack)

If something weird is happening, it is a good idea to at least try to 
tell the other side the connection blew up.

Maybe the other TCP is getting confused, and stopped sending packets or 
something weird like that. One should try to put it out of its misery with 
a RST instead of having it stay stuck. Stuck connections and sockets can be 
really bad.

>
>I wouldn't mind a RST packet, but I can't fault the server
>implementation for not sending one.
>
>						don provan
>						donp@novell.com



-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Mon, 01 Aug 1994 11:14:05 +1200
From:      GEOFF@waikato.ac.nz (Geoff Holmes)
To:        comp.protocols.tcp-ip
Subject:   Reposting: Job ad Deadline 9 Sept

Lecturer/Senior Lecturer/Associate Professor in 
Computer Science/Information Systems

Applications are invited for two positions in the Department of
Computer Science at the University of Waikato, Hamilton, New Zealand.

Outstanding candidates in all areas of Computer Science/Information
Systems will be considered, but databases and networks and communications
are of particular interest. Applicants should hold an advanced degree in 
Computer Science or Information Systems and must be committed to
teaching and scholarly research.

The Department of Computer Science has a complement of 28 academic
and support staff and is one of the largest departments in the
University. Its staff teach and conduct research in both Computer
Science and Information Systems areas. There are 2500 student
course enrolments, and majors are granted in five undergraduate
degrees, 40 students are currently enrolled in graduate study
at the masters and doctoral level in the Department.

As well as large networked IBM PC and Macintosh teaching laboratories,
departmental resources include SUN workstations, SGI Indy workstations,
NeXTs, hardware and communications laboratories, a variety of Unix servers,

and access to the University's VAX cluster.  Internet access to email 
and networks is available.

The University of Waikato is the fastest growing of the seven universities
in New Zealand and currently has over 10,000 students.  The campus and
surrounding area are very attractive, bordering a pleasant rural district
on the eastern edge of Hamilton, a modern city of 100,000.  Climate is
moderate... the grass grows year round... and social activities include
fishing, sailing, hiking, skiing, golf, rugby, soccer, tennis and cricket.
In short, the lifestyle and climate are unbeatable!

The present salary ranges are as follows:  Lecturer: $37,440 - $49,088 per
annum, Senior Lecturer: $52,000 - $67,080 per annum, Associate Professor:
$69,680 - $75,920 per annum.

Enquiries of an academic nature may be made to the Chairperson of the
Department, Dr Geoffrey Holmes, Email: geoff@waikato.ac.nz, 
telephone: 64-7-838-4528, fax: 64-7- 838-4155.  Information on the method
of 
application and conditions of appointment can be obtained from Personnel
and Management Services, The University of Waikato, Private Bag 3105,
Hamilton,
New Zealand, telephone 64-7-838 4003, fax: 64-7-856-0135, Email: rgtywp4@
waikato.ac.nz (via internet).  All applications quoting reference number 
A94/28 received by 9 September 1994 will be considered shortly thereafter.
Applications will be accepted until the positions are filled.

Places for appointees' children may be available in the creche run by the
Campus Creche Society (Inc).  Equal Opportunity is University policy.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 16:56:35 -0500
From:      flipper@pentagon.io.com (Peter Sierant)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <31m3on$bkc@newhub.xylogics.com>,
James Carlson <carlson@xylogics.com> wrote:
>In article <31lr9l$s4i@pentagon.io.com>, flipper@pentagon.io.com (Peter Sierant) writes:
>|> >
>|> >The router-requirements document says:

. . .

>|> 
>|> " No subnet SHOULD be assigned . . ."  Why not?  I realize the reasons 
>|> why the net or host portion can't be zero or -1, but why the subnet? The 
>|> rfc (950) is even a bit vague, stating SHOULD as opposed to MUST and 
>|> citing convention as the reason.  
>
>The recommendation is made because such subnets will have ambiguous
>broadcasts.  For instance, suppose you have 192.9.200.0 subnetted with
>255.255.255.192.  Now, is 192.9.200.255 a network broadcast (to all
>subnets) or a subnet broadcast to the 192.9.200.192 subnet?  How is a
>broadcast to *just* the 192.9.200.192 subnet formed?
>

Ahhh, finally a good reason. Thank you.
I can see how a test can be made in the routing algorithm: does the 
request come from a point that is non-local and unaware of the subnet? If 
so, then send to all, if aware, then send to net 192.  Or something. 
But I understand why it's not like that.

>|> The reason I care is that various manufacturers either support or don't 
>|> support, let's say,  1 bit subnets.  One the other hand, many 
>
>We're one of the ones who don't support 1 bit subnets.

for reasons I now understand.  Although because of the wasted addresses, I 
wish this was thought of early on and addressed.

>
>|> manufacturers don't support non-contiginous bits, which is clearly a 
>|> bug. There doesn't really seem to be a consensus.  I concerned that using
>
>How is that a bug?  Subnets should be contiguous.  What would be the
>benefit of having a non-contiguous subnet mask?  Is 255.255.255.129
>somehow more useful than 255.255.255.192?  In what case would this be
>true?
>
>I'd be willing to entertain support for such a feature, but I've never
>seen a convincing argument that it would be worthwhile.  It seems to me
>that you have the same number of bits either way -- but the contiguous
>case is much easier to handle.  (Binary searches of routing tables are
>much harder to do when the mask is non-contiguous ...)
>

I agree that using a LSB subnet instead of a MSB one is rather dumb.  The 
only reason I can see to do that is to make it easier for an 
"administrator of limited bandwidth" to understand his networks, since 
the net numbers are contiguous (ie, 255.255.255.7 yields nets 1,2,3,4,5,6)
(Yes this is a very poor reason. Feeding the admin to a pack of vicious 
badgers is a much more elegant solution.)

The point however, is that much IP software supports non-contiguous 
masks, like for instance Novell Netware, it is not illegal to do so, and 
some people out there do it. I've seen it with my own eyes, and it does 
work.  

If someone's software doesn't support what is a legal, if dumb, mask, it 
can be the cause of non-interoperablility. I cannot recommend without 
reservation IP software to my customers that doesn't support 
non-contiguous subnets, even though I recommend they change their netmask to 
a contiguous one. Changing it can be a very big deal to a large, entrenched 
installment, with no visible gain in robustness or performance.

I maintain that IP software that doesn't support non-contiguous bits is 
broken per the rfc.  Software should gracefully allow you to shoot 
yourself in the foot.  If I wanted software to decide what's good for me, 
I'd use Winders.

>|> a 2 bit mask on a class C address (255.255.255.192) causes you to lose 
>|> over half of your addresses.  Using a 3 bit mask, you still lose over 60 
>|> addresses, and are limited to only 30 nodes per segment. It's not like IP 
>|> addresses are unlimited.
>
>All of that is true.  By the way, it's easily provable that you get the
>most efficient usage of your IP numbers if you either (a) don't subnet
>at all, or (b) use a subnet and host field of the same width (id est,
>for a class C network, 255.255.255.240).
>

True. If you need more than 14 hosts per segment, though, it gets a little 
uglier.  Software should never artificially limit hardware's physical 
characteristics. 

>If you were at the Toronto IETF (and you believe the schedules), IPng
>will change the address space from 4 bytes to 16 bytes (!), with beta
>test next summer and actual deployment in January 1996.  (I calculate
>about 2E+30 IP addresses per square mile of surface area on the Earth.
>We probably will not run out again ...)

Ahh, but you limit yourself to Earth. I look forward to:
 
finger green.man@mars.sol.net :-)

Is there a place where I can get a good technical description of IPng and 
plans to co-exist with existing addresses as well as router issues 
between them?

>--
>James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
>Annex Software Support / Xylogics, Inc.               +1 800 225 3317
>53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

Thanks,
-- 
--Pete                                        Ugly box of mostly Microsoft 
flipper@io.com           
jblues@wintermute.tci.com                            
psierant@klaven.tci.com                                 ECNE  Linux  OS/2

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 94 17:08:51
From:      vidar@drue.unit.no (Vidar Vetland)
To:        comp.sys.sun.hardware,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Ethernet controllers for SUN workstations?


We are doing some measurement experiments of TCP/IP performance over
an Ethernet. We would like to know which kinds of controller that can
be put inside a Sun workstation. In particular we would like to know
which controllers that Sun Microsystems itself put into the
workstations they sell.

If possible we would also like to get some pointers to relevant
documentation and/or technical specifications.

Thanks in advance.

Vidar Vetland
Politecnico di Milano, Italy
Email: vidar@elet.polimi.it


-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 12:14:41 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <31kftl$8q3@zeus.fasttax.com>, phil@zeus.fasttax.com (Phil Howard) writes:
|> sej@psycfrnd.interaccess.com (Stephen Johnson) writes:
|> 
|> >I have not had good luck running Novell servers as routers with
|> >different subnet masks on different interfaces. Might be my problem,
|> >might not :)
|> 
|> I've run into this problem with other routers, too (no brand names will
|> be mentioned until I verify that it is not my fault).  In general I find
|> most routers have at least 1 or 2 "gotchas" in their configurability.
|> 
|> I've even seen routers that will ONLY support subnet masks on 8-bit
|> boundaries, so class C cannot even be subnetted with them.  Class B
|> has only one choice, and class A is limited to 2 choice (I think).
|> 
|> A few will let you do some things with a netmask specified by number
|> of bits in the network part and assume they are all high order bits.
|> I don't know of any that let you do much with explicit netmasks that
|> do not have all the 1 bits together.

The router-requirements document says:

 58         The bit positions containing this extended network number are
 59         indicated by a 32-bit mask called the "subnet mask"; it is
 60         recommended but not required that the <Subnet-number> bits be
 61         contiguous and fall between the <Network-number> and the
 62         <Host-number> fields.  No subnet should be assigned the value
 63         zero or -1 (all one bits).

So you shouldn't specify non-contiguous masks, but it is expressly
permitted.

Our older products did support non-contiguous subnet masks, but we've
dropped support for this in our future development projects.  In
general, it's just not a useful feature.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 18:19:09 EST
From:      Lew@mail.med.cornell.edu (Lewis Perin)
To:        comp.protocols.tcp-ip
Subject:   Do ephemeral port numbers vary?

It's typical for a client to connect to a server without specifying a local 
port number.  I've seen these port numbers called "ephemeral" or "anonymous".  
There's a wide range of local port numbers a protocol stack can choose among 
in this case.  It would seem reasonable for this port number to cycle through 
the range rather than repeat the same one with each new [re-]connection; this 
would probably make it easier to discard stray packets from a recently 
dissolved connection.  Moreover, the source code of one protocol stack I've 
read actually does this.  But that's obviously not much of a guarantee.

So, if anyone knows, please:

(1) Is a TCP and a UDP implementation required to make repeated requests for 
anonymous/ephemeral local ports yield different numbers?

(2) Do actual implementations do this?

Because (2) may generate lots of traffic, I'd gladly accept email and 
summarize the responses.

Thanks much,

      __          perin@med.cornell.edu (212)746-2946
 |   |_  \    / : Lew Perin
 __ |__  \/\/  : Home: (201)435-2679

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 13:33:43 GMT
From:      roberts@alpha (Jack C. Roberts)
To:        comp.protocols.tcp-ip
Subject:   Slow localhost ping? Need Help Fast!

Hello all,

I'm having a strange problem on a DG Aviion 4500 running DGU/X 5.4R3.00.
We started noticing that network applications were taking a long time to
connect. (telnet, rsh, X)  So much so, that under heavy loads we would get
entries in the streams log like:

tcpip     error     Aug 01  15:00:35  tcp(0): connection 192.48.117.207:1575
                                      192.48.117.19:6000 dropped
                                      (0122222022)

We're not absolutely certain when this started happening but we think it
was soon after the machine had lost power while in multi-user mode.

Doing a ping to another host will produce:

$ ping -s alpha
PING alpha (192.48.117.211): 56 data bytes
64 bytes from alpha (192.48.117.211): icmp_seq=0 ttl=255 time=3.392 ms
64 bytes from alpha (192.48.117.211): icmp_seq=1 ttl=255 time=2033.95 ms
64 bytes from alpha (192.48.117.211): icmp_seq=2 ttl=255 time=4038 ms
64 bytes from alpha (192.48.117.211): icmp_seq=3 ttl=255 time=6038.85 ms
64 bytes from alpha (192.48.117.211): icmp_seq=4 ttl=255 time=8041.29 ms
^C
--- alpha ping statistics ---
22 packets transmitted, 8 packets received, 63% packet loss
round-trip min/avg/max = 3.392/7038.55/14056.6 ms

The wierd thing about this is that it takes several seconds before the
ping actually prints anything but the first packet says the round trip
time was 3.392 ms.  I guess the initial delay could be before 'ping' actually
starts sending pings.

Here's the kicker.  Doing a ping to localhost (127.0.0.1) produces results
very similar to the above.

ping -s localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=255 time=2.642 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=255 time=2057.22 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=255 time=4094.39 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=255 time=6094.41 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=255 time=8086.53 ms
^C
--- localhost ping statistics ---
22 packets transmitted, 8 packets received, 63% packet loss
round-trip min/avg/max = 2.642/7089/14141.2 ms

Pings coming from another computer to the aviion work as they should.
(0 and 1 ms round trip times)

Does anybody have any ideas about why this could be happening?  Could
it be hardware?  If so, why does this problem show up with a localhost
ping?  If it's a software problem then what files could get hosed so that
things sorta work?

Thanks in advance,
Jack

--

----------------------------------------------------------------------------
|      Jack Roberts                                                        |
|      National Science Center Foundation      Usenet: roberts@nscf.org    |
|      P.O. Box 15577                          Phone:  (706) 868-3621      |
|      Augusta, GA 31919-1577                  Fax:    (706) 868-6088      |
----------------------------------------------------------------------------

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 15:11:14 GMT
From:      bortzmeyer@cnam.fr (Stephane Bortzmeyer)
To:        comp.protocols.tcp-ip,comp.unix.osf.osf1,comp.unix.programmer
Subject:   Increase the socket listen queue? (Was: TCP connection problem and how to interpret netstat output?)

In article <31j1co$815@sheckley.cnam.fr>, bortz@cnam.cnam.fr (Stephane Bortzmeyer) writes:

>The symptom is the following: most of the time, the server (which has, 
>at the present time, almost no other tasks, expect low-priority CPU-
>intensive jobs) replies instantaneously to the clients on the same 
>Ethernet. But very often we see delays of 10, 20, 40 seconds and often 
>Mosaic times out.
 ...
>Configuration: DEC 3000/600S with 128 Mb RAM, OSF/1 2.0. The HTTP 
>server is a local one (software written here).

One hypothesis: the socket listen queue is full. I made a test program 
and saw that, when more than n (n being the parameter given to the 
listen(2) system call) clients are waiting, netstat displays the 
last clients as being in the state SYN_SENT (no reply from the callee 
yet). I observe exactly the same thing when my Web clients are blocked.

If my hypothesis is correct, how to increase the maximum size of 
this queue? It defaults to 8 on OSF/1. It doesn't appear to be modifiable. 
I changed SOMAXCONN in /usr/include/sys/socket.h and rebuild the kernel 
with no results (only 8 clients can be in ESTABLISHED state).

Anyone has an idea on this change? (I don't have OSF/1 sources :-)

I made a Web page with the informations and the current state of work:

http://www.cnam.fr/Network/Infosystems/Tools/tcp-http-problem.html

Thanks in advance,

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
bortzmeyer@cnam.fr            Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

http://web.cnam.fr/personnes/bortzmeyer/home_page.dom

					
	

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 15:14:04 +0000
From:      Peter@bhcnt.demon.co.uk (Peter Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: Route a subnet with same net number?

In article <319vke$6e@acmez.gatech.edu>
           gt6444c@prism.gatech.edu "Chip Edwards" writes:

> I have a 10BASE-T ethernet connection an a machine which has
> access to the ethernet. I also have an additional ethernet card
> in the same machine to another machine. (using BNC).
>   I wish to route (forward) packet from the addional machine onto the
> network the 10-Base-T machine in on. I have access to addiontal
> IP numbers on the same net. Is it possible to route from the
> second machine to the first machine with an IP number same as that
> of the main net? I have done this once using the parallel port and arp.
> (I run Linux of the The first machine)
>   If I can not do this by using an IP number with the same network number
> as the main net, then I'll just have to telnet to the main machine then
> out on to the net.
> I have tried several combinations. 
> A summary,
>   
>   ------ ------ ------ ------   (BCN)    --------------------
>   |CPU | |CPU | |CPU | |CPU |<---------->|Additional Machine|
>   ------ ------ ------ ------            --------------------
>     |      |      |      |
>     |      |      |      |       
>    -------------------------
>    | Bridge  10Base-T      |---------------> To internet
>    -------------------------

My problem is similar (yet different :-) ...

We have a local LAN with approx 600 devices all running TCP/IP.
They all have their own (class B addresses)

Now, I have recently joined the Internet, and have discussed it's merits with
the Management that be, want to join one of our systems onto it and make the
NEWS, E-Mail, etc, available to our local users.

The idea would be to have a UNIX system (inital testing will probably be Linux)
connected to the LAN and a modem on COM1 to our Internet feeder (ie DEMON).

ie.

      --------
      | Unix |------COM1-------->Internet
      | Box  |
      --------
         |
         |
         |
       (===============Local TCP/IP Network===============)  
          |    |    |    |    |    |    |    |    |    |
          |    |    |    |    |    |    |    |    |    | 
          |    |    |    |    |    |    |    |    |    |
      Loads of IP Addresses (no doubt already in use in the real-world)


Does anyone know if the can be done ?

I know I can do something similar with a PC running Windows, but this isn't
acceptable.

This is possible as Windows packages don't share configuration files.

AFAIK _all_ Unix TCP/IP packages are going to use the same /etc configuration
files.

At the end of the day the operating system used is _not_ important, _but_
it _must_ be multi-user, multi-tasking, and be portable to an Intel PC.

(I know this limits the choice - NT, OS/2, Unix, etc).

Any help with this would be gratefully recieved.

BTW, please Email responses direct to me.


-- 
Peter Gross                      |Email:      peter@bhcnt.demon.co.uk
UNIX Systems Manager             |*********************************************
Brighton Health Care NHS Trust   |*  My opinions are my own, not my employers *
UK                               |*********************************************

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 16:18:21 GMT
From:      tomw@netcom.com
To:        rec.autos.marketplace,comp.protocols.tcp-ip,comp.infosystems.www,alt.wired,alt.winsock
Subject:   Results:  Internet Survey Results


Here are the results of the Internet Survey taken last month
I will soon get a webserver up with much more expanded Info!
If you want to take part in this survey then just cut this survey
out and put an X on the line to answer the appropriate question

For those who already have thanks! THERE ARE SEVEN NEW QUESTIONS
BELOW! ( PS THE MORE RESPONDANTS THE MORE WE WILL SEE INTO THE DATA! )

Internet World Wide Web User Survey July 1994		

Type of Internet Connection	User Count	
Raw Serial		          7	
Slip				 27	
PPP				 15	
Direct Connection	         42	
Other				  5	
Don't Know			  3	
Total Connections	       --99--	
		
Other Connectivity Issues      --Count--	
Do you use an Internet provider	 27	
Do you use a BBS	         13	
Is Slip or PPP hard to setup		
Yes:				 13	
No:				 18	
Are you a student ( or Staff )   14	
		
World Wide Web Host Type       --Machine Count--
Windows Workstation	         59	
Sun Workstation			 17	
Macintosh Worksation	          5	
Other Unix Platform	         24	
Other Platform			  6	
		
Total Workstations	      --111--	
		
Internet Service Usage	       --User Count--	
Do you read > than 10 Newsgroups 70	
Do you use Telnet	         72	
Do you use Ftp			 76	
Do you use a Gohper client	 58	
Do you use a WAIS client	 20	
Do you use a WWW client	         53	
		
Market Research Questions     --Count--		
Do you know what the World Wide Web is?		
Yes:				53	
No:				 2	
		
If you have never used WWW before do		
you plan on using a WWW client		
Yes:				12	
No:				 0	
		
If transactions were secure would you use the Internet		
to purchase goods and services?		
Yes:				66	
No:				 4	

Do you see the Internet as a way to  
publish documents or other media?	
Yes:				73 
No:				 0   

Total survey respondants      --80--


--------------------- SEVEN NEW QUESTIONS !!! ------------------------


Do you Find It Hard to find a specific piece of information on the Net
YES:
NO:


Does your site have a WWW server (s) set up yet
YES:
NO:


Does Your Workplace or site plan on setting up a WWW server soon
YES:
NO:


Do you use WWW at home
YES:
NO:


Do you use WWW at work
YES:
NO:


What is your occupation ( generally )

Buisness Executive
Technical Professional
Aministration
Sales Person
Marketing Type
Manager
Trades Person
Other


Would a WWW based tool with common text entry based Input, that "Knows how to
find things or do things" be useful
YES:
NO:


E-mail to tomw@netcom.com
thanks, will repost results, 
hopefully I will be "webbed" soon ( my sparc died :(


-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 16:36:17 GMT
From:      rdmastro@jpmorgan.com (Richard Del Mastro)
To:        comp.protocols.tcp-ip
Subject:   Re: I want to kill a TCP/IP connection, but ho

In article 2ff@flode.nvg.unit.no, agulbra@flode.nvg.unit.no (Arnt Gulbrandsen) writes:

>So what I want to do is force the server to notice that the other
>TCP endpoint has gone away.  Is there any way to do that?

Assuming that somewhere you are doing a select(), when the client
side of the connection is closed (either by the client doing
an explicit close() or by the OS after the client has "crashed"),
the select() should indicate a "read-ready" condition. At that
point, assuming you are then doing a read(), the read() will
return 0, indicating EOF, or in the case of a connected socket,
that the other side has gone away.
---


-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 13:49:06 +0200
From:      roque@master.di.fc.ul.pt (Pedro Roque Marques)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PCs as IP routers

Jon Lewis (jlewis@inorganic5.chem.ufl.edu) wrote:
: In article <31677n$ksk$1@heifetz.msen.com> acsgen@garnet.msen.com (Applied Computer Solutions) writes:
: >From: acsgen@garnet.msen.com (Applied Computer Solutions)
: >Subject: Re: PCs as IP routers
: >Date: 27 Jul 1994 17:58:15 GMT
 
: >Philip Burton (philip.burton@spacebbs.com) wrote:
: >: Does anyone have experience with PC-based TCP/IP packages that can do IP 
: >: routing?  under DOS?  under Windows?  

Around here we use a PC running Linux to route between to local ethernets ...
It's stable, fast and after a bug correction works real fine....
We use it allsoo to provide ppp and slip
IMHO a good solution


: |------------------------------------------------------------------|
: | jlewis@inorganic5.chem.ufl.edu   If the first address bounces    |
: |                                  let me know, and resend to the  |
: | jlewis@chem.ufl.edu              second address.                 |
: |                                  If the second address bounces   |
: | Jon Lewis                        something's seriously wrong.    |
: |                   Mime attachments are OK                        |
: | http://inorganic5.chem.ufl.edu  gopher://inorganic5.chem.ufl.edu |
: |                                                                  |
: |_____Finger jlewis@inorganic5.chem.ufl.edu for PGP public key_____|



-- 

	Pedro Roque (roque@di.fc.ul.pt)

	<a href="http://www.di.fc.ul.pt/~roque"> Home Page </a>

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 17:28:16 GMT
From:      acsgen@garnet.msen.com (Applied Computer Solutions)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: PCBridge as link to SLIP/PPP provider

Edward Vielmetti (emv@garnet.msen.com) wrote:
: If you have some old 386 or 486 machine handy, with a modest amount
: of disk space available, you could run Linux on it.  That would 
: get around the problem of having to hack on DOS based systems
: as well as give you a place to relay mail through.

Unfortunately, all I've got available are a few 286s, a few floppy
drives and a few 256KB SIMMs - stuff that we can't use even as
print or modem servers anymore.  Every other piece of still functioning
PC hardware we have is in use - and we still need more (and better)
PCs (and other computers).  We are on a shoe string budget.


-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 17:29:52 GMT
From:      chandler@chatham.progress.com (Peter Chandler)
To:        comp.protocols.tcp-ip
Subject:   Protocol Analyzers

I am looking for a good Software protocol analyzer (under $1000.00).
Can anyone recommend one ( make and model ).

thanks,

Peter Chandler.
 



-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 18:37:11 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <31lr9l$s4i@pentagon.io.com>, flipper@pentagon.io.com (Peter Sierant) writes:
|> >
|> >The router-requirements document says:
|> >
|> > 58         The bit positions containing this extended network number are
|> > 59         indicated by a 32-bit mask called the "subnet mask"; it is
|> > 60         recommended but not required that the <Subnet-number> bits be
|> > 61         contiguous and fall between the <Network-number> and the
|> > 62         <Host-number> fields.  No subnet should be assigned the value
|> > 63         zero or -1 (all one bits).
|> >
|> 
|> " No subnet SHOULD be assigned . . ."  Why not?  I realize the reasons 
|> why the net or host portion can't be zero or -1, but why the subnet? The 
|> rfc (950) is even a bit vague, stating SHOULD as opposed to MUST and 
|> citing convention as the reason.  

The recommendation is made because such subnets will have ambiguous
broadcasts.  For instance, suppose you have 192.9.200.0 subnetted with
255.255.255.192.  Now, is 192.9.200.255 a network broadcast (to all
subnets) or a subnet broadcast to the 192.9.200.192 subnet?  How is a
broadcast to *just* the 192.9.200.192 subnet formed?

|> The reason I care is that various manufacturers either support or don't 
|> support, let's say,  1 bit subnets.  One the other hand, many 

We're one of the ones who don't support 1 bit subnets.

|> manufacturers don't support non-contiginous bits, which is clearly a 
|> bug. There doesn't really seem to be a consensus.  I concerned that using

How is that a bug?  Subnets should be contiguous.  What would be the
benefit of having a non-contiguous subnet mask?  Is 255.255.255.129
somehow more useful than 255.255.255.192?  In what case would this be
true?

I'd be willing to entertain support for such a feature, but I've never
seen a convincing argument that it would be worthwhile.  It seems to me
that you have the same number of bits either way -- but the contiguous
case is much easier to handle.  (Binary searches of routing tables are
much harder to do when the mask is non-contiguous ...)

|> a 2 bit mask on a class C address (255.255.255.192) causes you to lose 
|> over half of your addresses.  Using a 3 bit mask, you still lose over 60 
|> addresses, and are limited to only 30 nodes per segment. It's not like IP 
|> addresses are unlimited.

All of that is true.  By the way, it's easily provable that you get the
most efficient usage of your IP numbers if you either (a) don't subnet
at all, or (b) use a subnet and host field of the same width (id est,
for a class C network, 255.255.255.240).

If you were at the Toronto IETF (and you believe the schedules), IPng
will change the address space from 4 bytes to 16 bytes (!), with beta
test next summer and actual deployment in January 1996.  (I calculate
about 2E+30 IP addresses per square mile of surface area on the Earth.
We probably will not run out again ...)

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 01:29:58 -0400
From:      weave@hopi.dtcc.edu (Ken Weaverling)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   CIX to restrict Internet access

(NOTE: Was not sure what was appropriate group to post this to. I scanned 
for an existing thread and didn't find any).

Is it just me, or am I missing something?

The August 1st issue of {Infoworld}, front page, has a story about how 
CIX is not going to route some packets from non-CIX members unless they 
pay a $10K annual fee, starting November 1st.

Is this just plain stupid or what?

Imagine a likely scenario. I am commercial company planning on putting up
a Web server, gopher, etc, to offer sales lit, support, etc, to my
customers and potential clients.  I find out that a lot of sites can't
reach it because they are behind providers that don't shell out the $10K
to CIX. I'd be friggin pissed and take my net business elsewhere. 

The value of the "net" is its connectivity. If CIX is going to become 
elitist, then they are hurting themselves as much as the net community in 
general. 

I also find it very ironic that most of the large ftp sites, web servers, 
etc, are on edu (and I assume non-CIX) hosts.  Will CIX members be 
allowed to access these, even if the reverse isn't true?  Maybe these 
sites should start charging CIX members access fees...

This could get real ugly.

-- 
Ken Weaverling          weave@dtcc.edu |*|  Wilmington: +1 302 573-5460
    Manager of Computer Services       |*|     Stanton: +1 302 454-3978
   Stanton/Wilmington Campuses of      |*|       WHOIS: KJW
Delaware Technical & Community College |*|

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 02:07:05 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: What are "sider" IP numbers?


In <31mi09$csb@ccnet.ccnet.com> jantypas@ccnet.com (John Antypas) writes:

>Recently, while shopping for an IP provider for a client, a vendor
>noted that the use of "sider" IP numbers was better because of the
>crunch on address space.
 
>I've never heard this term before.  What is a 
>"sider" number?  I assume it means a subnet of a class C address?

That's CIDR, prounounced <cider>. It means a SUPERNET, or group of
small (C or B -class, usually) nets that are advertised in one chunk.

CIDR stands for Classless Inter-domain Routing. See RFC1519.

--
John Hawkinson
jhawk@panix.com

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 19:46:01 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <31585s$rut@titan.mech.port.ac.uk> dcl@ee.port.ac.uk (Darren Lavender) writes:
>I have configured a novell server (v3.12) with 4 Ether cards to act as a gateway, 
>however because 3 of the cards are going to connect to a thin ethernet
>I did not want to waste 3 Class C subnets so I have broken down the last
>byte of the ip address and used the top 3 bits as additional net numbers, ie
>...
>Card 1 , Net=148.197.60.0,  netmask=255.255.255.0,   ip_add=148.197.60.41
>Card 2 , Net=148.197.64.32, netmask=255.255.255.224, ip_add=148.197.64.33
>Card 3 , Net=148.197.64.64, netmask=255.255.255.224, ip_add=148.197.64.65
>Card 4 , Net=148.197.64.96, netmask=255.255.255.224, ip_add=148.197.64.97
>...
>I have configured a couple of PC's on each of the nets with suitable ip 
>numbers and masks (LAN WorkPlace for DOS  v4.1 [tcpip.exe=v4.12]) and specified
>the 
>default routing address to be that of the Novell server interface on the same
>net, ie
>for PC on network 148.197.64.32, it has an ip_add=148.197.64.34 with
>a default router=148.197.64.33.

I assume the mask on the PCs is set to 255.255.255.224, correct?

>The PC's can only talk to the other hosts on the small subnet's OR a host
>on subnet 148.197.60.0 that has the server specified as the default router.
>(There are 2 other routers on this net, 1 = another server, the other is a
>3Com Netbuilder II acting as campus router).  I cannot ping any other hosts or
>vice-versa.
>
>I have checked using some snmp tools the routing tables of both the server and
>other hosts in the University and found that the routes are being distributed
>around our network.  

My informant on the NetWare TCP/IP development team thinks that the
route for 148.197.64.0/ff.ff.ff.0 will NOT be properly announced on
the 148.197.60.0/ff.ff.ff.0 subnet. (As someone mentioned, this is
unfortunately a step backwards from the original NetWare v3.11
TCPIP.NLM. In what was basically an accident of the implementation
approach I used, the 1.x TCPIP.NLM would "properly" announce this
route. When I saw this happen, it was such a surprise I had to go look
at the code to figure out *why*.)

Based on this, I'm guessing that the routes you saw being distributed
weren't really the correct ones; perhaps you saw 148.197.64.32 and
mistakenly thought it was correct.

If this missing route is the problem -- and it agrees with your
symptoms -- the straightforward solution would be to configure the
other two routers so they have static routes to the 148.197.64.x
subnet pointing to 148.197.60.41. In other words, fill in manually the
route 148.197.60.41 isn't advertising.

There are a couple of other possible solutions, but I'm not sure
they'll succeed.  First, it may be possible to entice 148.197.60.41 to
announce 148.197.64.x by adding a static route in *it*, aimed at, say,
the 148.197.64.33 interface. Second, it's also possible that you could
set the mask on the 148.197.64.33 interface to 255.255.255.0 (while
leaving all the PC's on that network with the 255.255.255.224 mask),
which should also induce the proper advertisement, but might confuse
the routing between the small subnets. (I'm not entirely sure
TCPIP.NLM will even accept that configuration, but it should.)
If setting a static route in the 3com router isn't practical, you
might try one of these approaches.

I'm told that all this is all straighten out in the next version of
the TCPIP NLM, which is slated to ship with the next releases of both
NetWare and MPR.

>Please help somebody ????

I hope so.

>bind ip to thin1 mask=255.255.255.224 addr=148.197.64.33

By the way, I recommend adding "defroute=yes" to each of these lines,
just in case someone hooks up a node that listens to RIP traffic
instead of using a configured default router. Since you mentioned that
you configured default routers on all the small subnet nodes, this
won't have any effect on the problem you're having, though.

						don provan
						donp@novell.com

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 20:21:09 GMT
From:      mark@ipctech.com (Mark Thomas)
To:        comp.sys.sun.admin,comp.unix.internals,comp.protocols.tcp-ip
Subject:   HELP: NFS problem on Sun 3/60


I'm having a problem with NFS on a Sun 3/60. It's running "Sun
UNIX 4.2 Release 3.5". I'm trying to nfs mount an exported
directory onto a PC running Lantastic for TCP/IP (which is an
NFS client like Sun's PC-NFS). If I perform a mount, and then
try to perform an "ls" or something from the PC, I get the
following errors on the console of the Sun:

svckudp_send: xdr_replymsg failed
svckudp_send: xdr_replymsg failed
svckudp_send: xdr_replymsg failed
svckudp_send: xdr_replymsg failed
svckudp_send: xdr_replymsg failed
svckudp_send: xdr_replymsg failed

What does this mean?

By the way, a second Sun 3/60 mounts fine from the 3/60 in
question, so I know NFS is working OK. Also, telnet, ftp, etc,
work from the PC so I know that the TCP/IP connection is valid.


 .------------------------------------------------.
|         Mark Thomas  <mark@ipctech.com>          |
| Systems Analyst / Network Integration Specialist |
| IPC Technologies Inc.               Richmond, VA |
 `------------------------------------------------'



-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 21:07:13 GMT
From:      chandler@chatham.progress.com (Peter Chandler)
To:        comp.protocols.tcp-ip
Subject:   TLI & WANs

I am looking for TLI drivers for Wide Area Network (WAN) protocols.
The WAN protocols are X.25, frame relay, SMDS, ATM, etc.  A TLI-WAN
driver should be supported on multiple hardware platforms.  Does
anyone know of a vender/product which allows TLI support with an
under laying WAN protocol? 

Thanks.

Peter Chandler. 



-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 03:52:57 -0400
From:      weave@hopi.dtcc.edu (Ken Weaverling)
To:        comp.protocols.tcp-ip
Subject:   Routing & broadcasts on a Novell Server

Speaking of Novell routing, I am having a devil of a time with the Novell
server refusing to send out broadcasts to nets it is connected to. For 
example (we have class B, subnetted to 255.255.255.0, so numbers below 
represent the subnet number)

72 =======================          =================== 76
           |                               |       |
          NOVELL                         HOST1   HOST2
           |                               |       |
84 ====================================================
                |
             CISCO
                |
92 ===========================================


Machine on 92 sends out a UDP broadcast to 138.123.84.255 ... The cisco
transmits it to the entire 84 line

Machine on 72 sends out a UDP broadcast to 138.123.84.255, Novell traps
it and deals with it as his own, does NOT send it to 84 line

Machine on 72 sends out a UDP broadcast to 138.123.76.255, Novell forwards
the broadcast out as he should....

This is screwing me up some since some server software we have sends out a
UDP broadcast to get a list of servers on that segment.  I send it to
84.255 and none of the servers respond (since Novell isn't forwarding it). 

The resident TCP/IP expert (bob@dtcc.edu) tells me the Novell isn't doing the
"right thing" as far as RFC919 and RFC922 says it should. From his mail
message he sent to me (which quotes some RFCs...)

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

6. Gateways and Broadcasts

   Most of the complexity in supporting broadcasts lies in gateways.  If
   a gateway receives a directed broadcast for a network to which it is
   not connected, it simply forwards it using the usual mechanism.
   Otherwise, it must do some additional work.

   When a gateway receives a local broadcast datagram, there are several
   things it might have to do with it.  The situation is unambiguous,
   but without due care it is possible to create infinite loops.

   The appropriate action to take on receipt of a broadcast datagram
   depends on several things: the subnet it was received on, the
   destination network, and the addresses of the gateway.

      - The primary rule for avoiding loops is "never broadcast a
        datagram on the hardware network it was received on". It is not
        sufficient simply to avoid repeating datagrams that a gateway
        has heard from itself; this still allows loops if there are
        several gateways on a hardware network.

      - If the datagram is received on the hardware network to which it
        is addressed, then it should not be forwarded.  However, the
        gateway should consider itself to be a destination of the
        datagram (for example, it might be a routing table update.)

      - Otherwise, if the datagram is addressed to a hardware network to
        which the gateway is connected, it should be sent as a (data
        link layer) broadcast on that network.  Again, the gateway
        should consider itself a destination of the datagram.

      - Otherwise, the gateway should use its normal routing procedure
        to choose a subsequent gateway, and send the datagram along to
        it.
-----------------------------------

  I think it's losing it around the second and third cases.  In fact, 
rfc1009 has this:



         e.  A gateway may forward a directed broadcast datagram, i.e.,
             a datagram with the IP destination address:

            { <Network-number>, -1}.

             However, it must not send such a directed broadcast out the
             same interface it came in, if this interface has
             <Network-number> as its network number.  If the code in the
             gateway making this decision does not know what interface
             the directed-broadcast datagram arrived on, the gateway
             cannot support directed broadcast to this connected network
             at all.

         f.  A gateway is permitted to protect its connected networks by
             discarding directed broadcast datagrams.


  Sounds like maybe it's brain-damaged (as in 'e') or maybe it's being
over-protective (as in 'f').  I'd go for the first myself.....
-- 
Ken Weaverling          weave@dtcc.edu |*|  Wilmington: +1 302 573-5460
    Manager of Computer Services       |*|     Stanton: +1 302 454-3978
   Stanton/Wilmington Campuses of      |*|       WHOIS: KJW
Delaware Technical & Community College |*|

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 22:00:18 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <1994Aug1.172730.24244@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
>In article <072894170213Rnf0.78@dmrt-2.dmrt.nl>, marco@dmrt-2.dmrt.nl writes:
>> sej@psycfrnd.interaccess.com (Stephen Johnson) writes:
>>>I have not had good luck running Novell servers as routers with
>>>different subnet masks on different interfaces. Might be my problem,
>>>might not :)
>> 
>> No, it's not your problem :-). Only the latest TCPIP.NLM (TCP187.EXE on 
>> ftp.novell.com) adds implicit support for this.
>>                                                
>	Well, it doesn't either. While internally there are such comments
>in the file, left over from the MultiProtocol Router product, we still use
>one subnet mask for all ports for the regular TCPIP.NLM. That and Proxy
>ARP are the two frequently made requests.

Novell's MultiProtocol Router v2.11, available from a reseller near you,
has proxy ARP and supports variable length subnet masks (obviously,
since proxy ARP doesn't make much sense without them). These features
aren't included in the TCPIP.NLM shipped with NetWare, unfortunately.
That's a battle I lost...

>	Also note that RIP does not support subnet masks, which means
>different masks on different nets makes things rather confusing with RIP.

Correct. RIP-II and OSPF would solve this problem, but we haven't
released them yet.

>	Maybe Don Provan would care to elaborate and correct, since he's
>a party of the first part.

Sorta. More an in-law relation these days: I haven't worked in the
TCP/IP group for a couple of years, but my wife's now the manager.

						don provan
						donp@novell.com

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Aug 1994 22:34:04 GMT
From:      shepperd@netcom.com (David Shepperd)
To:        comp.protocols.tcp-ip
Subject:   How does one "Supernet"?

I've looked through the FAQ's and the Comer books, but I didn't see any
reference to how one might combine contigiously numbered class C networks into
a single "supernet". It seems to me the simple thing to do would be to set the
netmask to say, 0xFFFFFE00 to get a 512 node network from 2 class C networks,
but when I ifconfig the Sun le0 port with that netmask, SunOS "fixes" it for
me and changes it back to 0xFFFFFF00. Dell SVR4 does the same thing. 

Anybody have any ideas?

Reply via email and I'll summarize.
-- 
Dave Shepperd.          shepperd@netcom.COM  or  netcom.netcom.com!shepperd
The company probably doesn't know what I say or do, but they pay me anyway.


-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 1994 22:48:13 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <31mff4$ilm@pentagon.io.com> flipper@pentagon.io.com (Peter
Sierant) writes: 

    I maintain that IP software that doesn't support non-contiguous bits is 
    broken per the rfc.  

There is no currently active RFC that requires non-contiguous masks.  The
citation that was given was from the old router requirements draft, which
is NOT up to date, has "historical" status and is broken in many small
ways.  Further, the next version of the router requirements draft is very
likely to remove this and deprecate non-contiguous masks, as well as fix a
number of small non-CIDRisms.

Tony

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 08:53:44 -0500
From:      flipper@pentagon.io.com (Peter Sierant)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <31mifd$5np@cronkite.cisco.com>, Tony Li <tli@cisco.com> wrote:
>In article <31mff4$ilm@pentagon.io.com> flipper@pentagon.io.com (Peter
>Sierant) writes: 
>
>    I maintain that IP software that doesn't support non-contiguous bits is 
>    broken per the rfc.  
>
>There is no currently active RFC that requires non-contiguous masks.  The
>citation that was given was from the old router requirements draft, which
>is NOT up to date, has "historical" status and is broken in many small
>ways.  Further, the next version of the router requirements draft is very
>likely to remove this and deprecate non-contiguous masks, as well as fix a
>number of small non-CIDRisms.
>
>Tony

I was actually refering not to the quoted snippet, but to rfc950, which I 
understand to be the current rfc pertaining to IP subnet masking. As I am 
a TCP/IP neophyte, there may be something newer that I'm unfamiliar with. 
Can you point me to some newer documentation?

Thanks,
-- 
--Pete                                        Ugly box of mostly Microsoft 
flipper@io.com           
jblues@wintermute.tci.com                            
psierant@klaven.tci.com                                 ECNE  Linux  OS/2

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 01:51:25 GMT
From:      edleslie@elearn.edu.yorku.ca (Ed  Leslie)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Help! Disabling Shell Access from Telnet

Marc B. Grant (marcbg@netcom.com) wrote:
: What setup do I need to use to disable the subsehll access from the 
: telnet> prompt when someone is on my system?  The user is logged on from 
: a captive account, and is automatically connected to a remote host.  
: However, if he enters the escape sequence and reaches teh telnet prompt, 
: then enteres the "!" for the subshell command, he has access to the 
: operating system.  IS there anyway of locking this out?

Do a man telnet and find out how to disable the escape character on your
implemenation. On some it is telnet -e ip.dot.address, on others it is
telnet -e '' ip.dot.address. Be aware, though that things vary a *lot*. On
an AIX for example, the -e switch is used to set the terminal emulation.

How I *do* love standards.....

Ed
P.S. Oh yeah, on some, you must give the telnet command, and *then* at the
telnet> prompt, type set esc off (or set esc 0). :P

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 08:45:21 -0400
From:      weave@hopi.dtcc.edu (Ken Weaverling)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In article <31o2m4$f04@orff.theo-physik.uni-kiel.de>,
Roland Kaltefleiter <kaltef@theo-physik.uni-kiel.de> wrote:
>
>You will find a thread in "alt.internet.services" about that.

You ain't kidding! Thanks for the pointer (and I set follow-ups there too)

>In former times there were only some NON-members. But know more and more commertial
>Internet Service Providers come up, use CIX routes and do not pay for that.
>And because the do not share any costs of international lines, they can offer connectivity
>cheaper. So others pay for their connectivity. Do you find that all right ?

Of course not.  The article in Infoworld was highly misleading then. They
kept referring to CIX as "commercial providers" and that half of the
Internet is "commercial accounts" which implies that the other half will
be the guys "restricted."

>P.S.: As I see it, your internet provider ist "sura.net". They are not small and they
>should be member of CIX. (I think they are). 

Very good, yes, and we pay Suranet a nice chunk of change for our
connection to (in addition to obvious charges to our ROBC for the lease
lines), which I understand is nothing compared to what our neighbor, the
University of Delaware, pays Suranet.

Thanks for pointing me to alt.internet.services. Anyone following up this
note, please honour my follow-ups to alt.internet.services. Thanks.


-- 
Ken Weaverling          weave@dtcc.edu |*| My opinions .NEQ. college's position


-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 09:40:58 -0400
From:      weave@hopi.dtcc.edu (Ken Weaverling)
To:        comp.protocols.tcp-ip,news.admin.misc,alt.internet.services
Subject:   Re: CIX to restrict Internet access

I am following up my own post with info I got, hoping to squelch some 
of the misinformation my post had in it.

In article <31na0m$6pq@hopi.dtcc.edu>,
Ken Weaverling <weave@hopi.dtcc.edu> wrote:

>(NOTE: Was not sure what was appropriate group to post this to. I scanned 
>for an existing thread and didn't find any).

As Roland Kaltefleiter pointed out (thanks), there is a big discussion
over in alt.internet.services on it with a lot of really good technical
descriptions of this.

>Imagine a likely scenario. I am commercial company planning on putting up
>a Web server, gopher, etc, to offer sales lit, support, etc, to my
>customers and potential clients.  I find out that a lot of sites can't
>reach it because they are behind providers that don't shell out the $10K
>to CIX. I'd be friggin pissed and take my net business elsewhere. 

A post to alt.internet.services explained this really well in one sentence.

From article <318ac3$4g5@panix.com>, ak@panix.com (Andrew Kantor) states:

> That' not what this is about. This is about non-CIX traffic routing 
> *through* the CIX network, not routing *to* it.

This makes perfect sense to me (*sound of hand slapping forehead*). I
usually read like mad before posting. I just didn't find the correct group
that was discussing this.

Followups set to alt.internet.services and thanks again to Roland for
pointing me to the correct group.  (And I still say the Infoworld article
was misleading as hell...)

-- 
Ken Weaverling          weave@dtcc.edu |*| My opinions .NEQ. college's position


-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 05:28:08 GMT
From:      pdh@netcom.com (P D H)
To:        comp.protocols.tcp-ip
Subject:   Re: IP-routing using RAW sockets

atlnafl@zeus.datasrv.co.il (Naftaly Lerman) writes:

>Can anyone suggest how I can access all IP traffic both entering and
>leaving a host using the standard BSD socket interface services?

You may be able to make your program act like a process-based packet
filter such as the "screend" program.  It has some interface on some
systems (I understand this works on BSDI for instance) allowing it
to intercept all packets.  Maybe this is what you are looking for.

See:
  ftp://decuac.dec.com/pub/sources/screend.tar.Z
  ftp://gatekeeper.dec.com/.2/DEC/screend/.screend.tar.Z
  ftp://gatekeeper.dec.com/.c/KITS/SOURCE/SCREEND/SCREEND.TAR
  ftp://vcdec.cvut.cz/.P2/pub/internet/screend/screend.tar.gz
  ftp://vcdec.cvut.cz/.P4/pub/dec/decuac.dec.com/sources/screend.tar.gz
  ftp://vcdec.cvut.cz/.P4/pub/dec/screend.tar.gz

Another alternative is to not use a Unix system at all and go with
a modified router package such as "pcroute".  If you want to tunnel
with UDP, it should be relatively easy to implement that if it is
not already in the package.

See:
  ftp://casbah.acns.nwu.edu/pub/pcroute/pcroute2.24.src.tar.Z
  ftp://ftp.uu.net/systems/ibmpc/msdos/pcroute/pcroute2.24.src.tar.Z
  ftp://ftp.waseda.ac.jp/pub3/MSDOS/pcroute/pcroute2.24.src.tar.Z

-- 
    Phil Howard KA9WGN    |    If this is an information superhighway,
    pdh@netcom.com        |    then where is the nearest airport?

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 05:41:18 GMT
From:      pdh@netcom.com (P D H)
To:        comp.protocols.tcp-ip
Subject:   Re: tunneling

electro@engg.ksu.edu (Eric L Patterson) writes:

>Hi.  Does anyone have any information on tcp "tunneling"?
>I have a slip connection to our campus, and a small network
>at home.  However, our slip admin won't let the slip router
>run rip (allowing me to route packets for any of my machines
>at home thru the slip connection).  If i try to route an ip
>other than that of the actual slip ip, the slip router
>bounces them back.  Is there a way to encapsulate and
>de/encapsulate them at either end of the slip line?

It is very common for a group of computer science students to
get together and live in a large apartment or house.  These
days they all have one or more computers of their own and will
often be seen networking them together.  It would make sense
for school they go to which provides SLIP/PPP access to
accomodate a subnet through a dialup SLIP/PPP line in order
to free up valuable phone lines and modems.  Without this
those computer science students in the house together might
very well get individual phone lines and use up four phone
lines instead of just one.

This is a practice that should be encouraged.  It is too bad
that so many schools don't really look at the problem in detail
and figure out good solutions.
-- 
    Phil Howard KA9WGN    |    If this is an information superhighway,
    pdh@netcom.com        |    then where is the nearest airport?

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 05:59:28 GMT
From:      pdh@netcom.com (P D H)
To:        comp.protocols.tcp-ip
Subject:   are there any generic addresses?

Are there any generic addresses?  What I am thinking of here is a set of
addresses which have been set aside to never appear on the open internet
but can be used by any organization on its own internal-only networks
for purposes not needing to go outside.  One advantage of this is that
this same addresses can be duplicated in each organization.

Of course I could just "steal" any address.  But I would want to make
these "stolen" addresses are not routed out to the open network and
there may well be machines in a "common area" that wish to communicate
with both the open internet as well as the isolated network.

The purpose of "stealing" addresses would be to get more addresses
without having to acquire more of the address space needlessly since
much of the network would be isolated.  It just seems to me that if
some addresses were set aside for this it would be easier to deal with.
Those organizations where all machines might need to have open internet
access or otherwise might be internet visible would not be able to take
advantage of this, obviously.

-- 
    Phil Howard KA9WGN    |    If this is an information superhighway,
    pdh@netcom.com        |    then where is the nearest airport?

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Aug 1994 19:39:35 -0800
From:      carr@esl.com (John A. Carr)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Multi-homed 4.1.3 Sparc 10

I'm attempting to configure a non-routing, multi-homed sparc 10.  There
are three ethernet interfaces, le0, le1, and le2.  We have a subnetted
class B network, netmask 255.255.252.0.  One network carries two subnets,
xxx.xxx.144.0 & xxx.xxx.152.0.  A second network carries xxx.xxx.148.0. 
There's a router which routes between these three networks.  That all
works fine.

I want my 4.1.3 Sparc 10 to have addresses and interfaces on all three
networks.  I have the following configuration in /etc/rc.local:

ifconfig le0 xxx.xxx.146.11 netmask + broadcast xxx.xxx.147.255
ifconfig le1 xxx.xxx.148.90 netmask + broadcast xxx.xxx.151.255
ifconfig le2 xxx.xxx.152.253 netmask + broadcast xxx.xxx.155.255

This seems to work OK.  I can see the node on all three interfaces.

I'm also running in.routed -q.  The problem comes when I receive a RIP
packet from some other router on the 144 or 152 network.  I push it back
out after decrementing ttl & suck it back in & out until the packet dies. 
If I kill routed, it still does the same thing.  Why?  

How can I just receive RIPs on any of my interfaces, update my routing
table, and not propagate them?

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

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 94 11:42:37
From:      mukesh@lucknow.eng.sun.com (Mukesh Kacker)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection establishment



>   I just wrote a small test program to simulate this and sure enough,
>   4.4BSD (and 4.4BSD-Lite) and Solaris 2.3 have this bug.  I'd bet
>   IRIX 5.x also has it, as that's the system that the original poster
>   was using, although I don't have access to IRIX.  Earlier systems
>   (SunOS 4.1.3, AIX 3.2.2, and the old Lachman SVR4 code) are fine--the
>   client retransmits the ACK when it receives the duplicate SYN/ACK.
>

Yes this was a bug in Solaris 2.3 and it is fixed in a recent
patch to the bug
1155951: TCP 3-way handshake doesn't complete if last ack is lost

(Patch is 101318 rev 46 and greater for those interested).
It is fixed in yet-to-be released Solaris 2.4


-Mukesh Kacker

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 08:07:22 GMT
From:      helberg@lodsun1.lod.uni-karlsruhe.de (Thomas Helberg)
To:        comp.protocols.tcp-ip
Subject:   Newbie Question on using RAW SOCKETS

I want to use the RAW Socket interface on a HPUX A.09.01 E 9000/755. 
As far as I am right now I must create a complete IP-Packet incl. IP header
,e.g UDP header and the user data. As a first example I want to use a simple
UDP EchoServer. 

And here are my questions !

Are there any good docs about the RAW Scokets ? 

Could anyone eventually post or e-mail me an example source ? 
 
What about the checksums ? 
Must i evaluate them with the src.|dest. address|port in netbyteorder or host byte
order ?

In general must all the data  changed to netbyte order ?

In my own program there must some fatal errors, because so far on the server side,
it is the next hop, nothing ever arrive.
So could you please have a look at the following programm fragment and check if I
make any principle mistakes ?  


Thanks in advance 

Thomas Helberg


e-mail: helberg@ask.uni-karlsruhe.de



.... /* All the includes */

struct opacket {
  struct ip ip;
  struct udphdr udp;
  char data [100];
};


short ipcksum(unsigned short*, int);  // IP-cksum(&header, numberofwords)
short udpcksum(struct opacket* );     // UDP cksum	


struct opacket* outpacket;
struct sockaddr whereto;
....  


int main()
{
   int sock, type, sockdgram;
   int addrlen;
   int datalen = 0;
   int TOS = 0;
   int outchars, count, count2;
   struct hostent *hp;
   struct servent *sp;
   struct sockaddr_in myaddr;
   struct sockaddr_in whereto;
   struct sockaddr_in *to = (struct sockaddr_in*)&whereto; 
   struct sockaddr_in *from;
   
   memset ((char *)&myaddr, 0, sizeof(struct sockaddr_in));
   memset ((char *)&peeraddr, 0, sizeof(struct sockaddr_in));
   memset((char*)&whereto, 0, sizeof(struct sockaddr));
  

   if ((hp = gethostbyname((char*)hostname)) == NULL) {
      cerr << hostname << " not found in etc\n" << flush;
      exit(1);
   }
   
   to->sin_family = hp->h_addrtype;

   memcpy((char*)&to->sin_addr,hp->h_addr, hp->h_length);
   
   if ((sp = getservbyname((char*)service, protocol)) == NULL) {
     }

   to->sin_port = sp->s_port;     

  datalen += sizeof(struct opacket);


  if (datalen <0 || datalen >=MAXPACKET - sizeof(struct opacket)) {
     cerr << " packetsize s must be 0<= s " << MAXPACKET - sizeof(struct opacket)\
	<< endl < flush;
     exit(1);
  }
  
   outpacket = (struct opacket*) new unsigned[datalen];
 
   memset((char*)outpacket,0,sizeof(struct opacket));   
   
 
  long ident = (getpid() & 0xffff)  | 0x8000; 
  
  myaddr.sin_port = htons(ident);  // a new port 
   

  if ((sock = socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) < 0) {
      cerr << " socket creation failed : " << sys_errlist[errno] << endl << flush;
      exit(1);
   }
  
   struct ip *ipptr = &outpacket->ip;
   struct udphdr *udp = &outpacket->udp;

   ipptr->ip_v = IPVERSION;
   ipptr->ip_hl = 5			
   ipptr->ip_tos = 0;  			// type of service   
   ipptr->ip_len = datalen; 		// total length   
   ipptr->ip_id = 0;
   ipptr->ip_off = 0;
   ipptr->ip_ttl = 30;			// time to live
   ipptr->ip_p = IPPROTO_UDP;
   ipptr->ip_dst = to->sin_addr;	// already in netbyte order ?
   ipptr->ip_src = myaddr.sin_addr;	// already in netbyte order ?
   ipptr->ip_sum = 0;
   ipptr->ip_sum = htons(ipcksum((unsigned short*)ipptr,5));

   udp->uh_sport = ident;		// netbyte order 
   udp->uh_dport = to->sin_port;   	// netbyte order
   udp->uh_ulen = (u_short)(datalen - sizeof(struct ip));
   udp->uh_sum = 0;
   udp->uh_sum = (u_short)udpcksum(outpacket);
   

   if ( (outchars = sendto(sock,outpacket, sizeof(datalen),0,\
	            &whereto, sizeof(struct sockaddr)))!= sizeof(datalen)){
    cerr << " can't send full packet " << sys_errlist[errno] << endl << flush ;
    exit(1);
   }   
      
   if ( (shutdown(sock,1)) == -1) {
      cerr << "unalble to shutdown socket " << endl << flush;
      exit(1);
   }
        
  int fromlen;

  fromlen= sizeof(*from);

  if ((count = recvfrom(sock,inbuf, sizeof(inbuf), 0, 
			(struct sockaddr *)from, &fromlen)) == -1) {
     cerr << " recv failed :" << sys_errlist[errno] << endl << flush;
     exit(1);
  }
  
 cout << (char*) inbuf << " received " << endl << flush;
      
 return 1;
}



   
   
   

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 20:55:35 -0700
From:      chrisj@puffin.com (Chris Jewell)
To:        comp.protocols.tcp-ip
Subject:   Re: are there any generic addresses?

In article <pdhCty3B4.BDv@netcom.com>, P D H <pdh@netcom.com> wrote:
>Are there any generic addresses?  What I am thinking of here is a set of
>addresses which have been set aside to never appear on the open internet
>but can be used by any organization on its own internal-only networks
>for purposes not needing to go outside.  One advantage of this is that
>this same addresses can be duplicated in each organization.

RFC 1597, ``Address Allocation for Private Internets'' provides a
single class A network, 10, a group of 16 class B networks, 172.16
through 172.31, and a group of 256 class C networks, 192.168.0 through
192.168.255.  I suggest reading the RFC before you start using that
address space.
-- 
Chris Jewell    chrisj@puffin.com    1341 Ramona Ave    Hollister CA USA 95023

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 10:35:31 GMT
From:      schoenau@salyko.cube.net (Thomas Schoenauer)
To:        comp.protocols.tcp-ip
Subject:   UDP multicast

I want to use UDP for multicast. Is there a common solution for that
or must I use UDP broadcast ? Whow high are the performance costs
of broadcast compared to multicast ?

	Thanks, Thomas


--

Thomas Schoenauer                                 schoenau@cube.net
Ernst-Krebs-Str. 3                                Fido: 2:2480/66
D-82131 Gauting                                   Tel+Fax: 089/8508295         

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 10:41:43 GMT
From:      heibu@prz.tu-berlin.de (Heinrich Buschermoehle)
To:        biz.sco.general,comp.unix.internals,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: interesting socket questions - expert advice needed

In article <sej.775529223@interaccess> sej@psycfrnd.interaccess.com (Stephen Johnson) writes:
>
>lprimak@hope.nyc.ny.us (Leonard Primak) writes:
>
>>When I have many clients connecting to the TCP server one after another,
>>and the TCP server exits after closing all active and passive sockets,
>>I see a lot of TIME_WAIT conditions on the sockets.  Furthermore,
>>I cannot re-start the server until all of these TIME_WAITs are gone.
>>I get "Address already in use" error.
>>I read about SO_LINGER option, and it does work, but if I use it,
>>the manual says that I will lose any data that is pending to be delivered
>>whhen close() occures.  What is the proper way to avoid this situations?
>
>I don't think I qualify as an expert but I think I know the answer to this 
>one.  If I remember my network programming tutorial correctly, after a tcp
>connection is closed, the port cannot be used again for some time afterwards.
>The time is twice some value (I can't remember) but it falls out to about 
>30 - 60 seconds.  This is to keep any packets from a closed connection
>still floating around in the ether from showing up and confusing a new
>connection reestablished on that same port. 

You should try to issue the following 
	setsockopt(s, SOL_SOCKET, SO_REUSEADDR, 0, 0)
just before calling the bind.

Heinrich
-- 
Dipl. Inf. H.  |  INTERNET: uri@cs.tu-berlin.de      heibu@prz.tu-berlin.de
Buschermoehle  |  X.400:   s=uri; ou=cs; p=tu-berlin; a=d400; c=de
Work:     phone: +49 30 314-26822    fax: +49 30 314-21114
Private:  phone: +49 30 6246509      fax: +49 30 6239828

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 10:47:03 +0000
From:      RArmitag@semact.co.uk (Richard Armitage)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Help! Disabling Shell Access from Telnet

In article <marcbgCtvrEH.HGo@netcom.com> marcbg@esy.com writes:
>What setup do I need to use to disable the subsehll access from the 
>telnet> prompt when someone is on my system?  The user is logged on from 
>a captive account, and is automatically connected to a remote host.  
>However, if he enters the escape sequence and reaches teh telnet prompt, 
>then enteres the "!" for the subshell command, he has access to the 
>operating system.  IS there anyway of locking this out?
>
>Thanks in advance!!
>
>-- 
> Marc Grant                                          
> Home: marcbg@netcom.com                             Telephone: 214-205-4593
> Office: marcbg@esy.com                                  Amateur Radio N5MEI
>              "The road to enlightment is chuck full o' potholes"

You could try setting the "SHELL" environment variable on the initial
system to "/dev/null" and see if that works.

Richard Armitage

=---------------------------------------------------------------------=
| InterNet : RArmitag@semact.co.uk | Fido : Richard Armitage@2:254/14 |
=----------------------------------=----------------------------------=

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6

mQCNAi4+kmMAAAEEAKhuAsBAsfXl0q3CRIsVoqTuDOyicy5lXnAxyGf+5STEh7yD
7ORkyh4GoxE11DsLDvzEChuXIWVXXw9mg0hjYMocD8LmJtlAudsFmUXxBnh0wZc2
IJG3288245GaaGNIIgWg4Bk/192G5Mr7Guvh48ZqB3hrHmvTBj9+ULmMGCFBAAUR
tCtSaWNoYXJkIEouIEFybWl0YWdlIDxSQXJtaXRhZ0BzZW1hY3QuY28udWs+iQCV
AgUQLj59sz9+ULmMGCFBAQF89AP+MwK5xvQbthg7M4FOqHlwIVAmzZoa+nrk4g0o
Ioj1SepEwiGvYenNOayBm2jnxKFHKJhH2EwF0fWDkn1XigT+3auvUNPZxMFzqWlt
vXl1sqeCIfVWv0Gx8ypuJ8qACeLNuxjekBbAC8VJGSkgEQoqppi/r1Y2mu9WAl+7
zT56bQ8=
=d609
-----END PGP PUBLIC KEY BLOCK-----


-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 11:17:17 GMT
From:      bsaffo01@cad.vmss.gmeds.com (Brian H. Safford)
To:        comp.protocols.tcp-ip
Subject:   Keepalive Timer?

I'm running DCA's RLN Gateway, and my client machines run the RLN client with 
Novell's Lan Workplace TCP/IP stack.  I use DCA's Irma Workstation for Windows 
to access our mainframe system via TN3270.  Once I start a 3270 session, if I 
don't press any keys for 5 minutes, my TCP/IP stack dies.

A tech support person from DCA told me the fix was to enable filtered 
broadcasts on the client.  Something about a "keepalive timer" used an IP 
broadcast mechanism.

Can anyone give me some detail on this?

Thanks in advance,
Brian Safford

+-------------------------------------------------------------+
| Brian H. Safford         EMAIL: bsaffo01@cad.vssm.gmeds.com |
| Electronic Data Systems  PHONE: (810) 492-7967              |
 +-------------------------------------------------------------+
| NOTE: The views and opinions expressed herein are mine,     |
| and DO NOT reflect those of Electronic Data Systems Corp.   |
+-------------------------------------------------------------+

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 13:39:17 GMT
From:      leighd@central.susx.ac.uk (Leigh Dodd)
To:        comp.protocols.tcp-ip
Subject:   List of UDP/TCP (Services) REQUIRED

Hi All
	Where can I get (From the NET), a list of port numbers and function
(brief describiction will do) of each of the udp/tcp ports in the /etc/services
file ?.

	ie bootps	67/udp	#Use for bootp ..etc (ports 1 to 65535 !!)

Thanks

Leigh

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

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 14:48:19 GMT
From:      stephen@memex.co.uk (Stephen Marley)
To:        comp.unix.programmer,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.unix.questions
Subject:   SUMMARY - Detecting client death, keepalives etc

Hello,

Thanks to everyone who posted or mailed a reply to my questions about
detecting client death on a TCP connection. Below is a summary of those
replies I received. (I may have missed some news postings because of trouble
with our feed. Please email me if this is the case).

The general consenus was to write my own application level keepalive or ping
mechanism and to read W. Richard Stevens' TCP/IP Illustrated ;)

My original posting:
>I'm sorry for asking this FAQ again, "What is the best way for a server
>to detect client death or host crash on a TCP socket connection?".  I
>have searched our news archives for similar questions and solutions and
>although I have seen replies from the likes of Richard Stevens, I'm
>still unclear on several points. I've got both the "Unix Network
>Programming" and "Advanced Unix Programming" books but they don't have
>much stuff on this problem. (I'll buy the new one soon ;)
>
>The scenario is as follows: PC clients running on Winsock and FTP's PC/TCP 
>connected to a Unix server (could be SunOS4, Solaris2.3, AIX, SVR4 etc. )
>I'm currently playing with a Solaris2.3 system, mainly because I can use
>`ndd' to change the tcp-keepalive-interval for testing purposes. (How
>do you do it on SunOS4 BTW?). The server just sits on a recv() waiting for
>client requests, there is no server-client `ping' protocol implemented. 
>
>My problems/questions are: 
> 
>1. How can the server catch the following events and exit?
>   a) The client program crashes (nothing is being sent over the connection).
>   b) The client machine gets rebooted
>   c) The ethernet cable gets disconnected.
>
>2. Why doesn't keepalive seem to work? I've set it to a minute with ndd, 
>   pulled the cable, waited and nothing. How long do you have to wait in total?
>   Does changing the tcp driver parameters with ndd take effect immediately?
>   (Yes, SO_KEEPALIVE option is set)
>
>3. If I use select() and recv(), timing out the select every ten seconds
>   and probing the client with garbage OOB data I get a connection timed
>   out after ~2.5 minutes, *even though the connection is fine*.
>   Why 2.5 minutes; I mean what tcp timeout parameters contribute to this 
>   figure? Why does it timeout when the connection is OK? I thought the 
>   client would just ack the non-inline OOB data.
>
>4. Why don't I always get `connection reset by peer' when I reboot the PC?

Paul Smith <cgi@crl.com> wrote:
>
>I believe that my testing under SVR4.2 found that my client and server
>(TCP/IP) behaviour was acceptable and timely in how fast a disconnection
>for any reason was propagated to the remaining ciruit participant.
>
>I was NOT useing blocking recv()'s though..  I enabled SIGIO/SIGURG on
>error and hangup and I believe that in the async IO with signals 
>enabled, I got signaled quit fast for the many possible scenarios:
>with on-going traffic, w/o traffic client/server closes socket, or 
>exits, physical layer disconnected with and w/o traffic etc..
>

I didn't try this approach so I'm not sure if it would work for me.

Dr. Charles E. Campbell Jr. <cec@gryphon.gsfc.nasa.gov> wrote:
>
>Here's an answer to 1a, anyway...
>
>I've found that when sockets die:
>
>   1) a select           returns socket-ready-to-read
>   2) recv with MSG_PEEK returns nothing-on-that-socket
>

This is much the same as read() or recv() returning 0 (ie EOF) to indicate
socket closure.  But I don't think that closure of descriptors is guaranteed 
under Winsock when an application crashes as it would be under Unix.

Jim Service <jservice@bart.candu.aecl.ca> wrote:
>I followed the example source in program 15.29 of "Advanced Programming in
>the UNIX Environment".  To summarize, on return from the select(), if a read
>descriptor is set but read() returns 0 bytes then you may assume the client
>has closed the connection.  I have also found that the client has to be
>running completely in the background (using setsid()) in order that the
>kernel will release the socket connection once it is closed.
...

Again, do sockets get closed when a Windows program crashes?

Nick Felisiak <nick@tweed.demon.co.uk> wrote:
>One of the most important and useful things about TCP is that it is *very*
>resiliant.  For instance, if my cheap old modem drops the connection while
>talking to Demon, I just redial, and any TCP connections established before
>the drop (usually) recover.  I like this.  Especially 2.4Mb into a 2.5Mb
>file transfer :-).  The only really satisfactory way to ensure the other
>end of the connection is still there is to poll it at the application level.
>
>> My problems/questions are:
>>
>> 1. How can the server catch the following events and exit?
>>    a) The client program crashes (nothing is being sent over the connection).
>>    b) The client machine gets rebooted
>>    c) The ethernet cable gets disconnected.
>
>Nothing is sent, so the server doesn't know, in each of these cases.
>

Yes I appreciate this now.

>
>>2. Why doesn't keepalive seem to work? I've set it to a minute with ndd, 
>>   pulled the cable, waited and nothing. How long do you have to wait in total?
>>Does changing the tcp driver parameters with ndd take effect immediately?
>>(Yes, SO_KEEPALIVE option is set)
>>
>
>Recommended practice with keep-alives (rfc1122) is to survive an outage of
>at least 2 hours!  The main value of keep-alives is for a process to be
>notified that the other end has gone away; however, this will only happen
>after the remote system has rebooted, sees a packet for a non-existant
>connection and sends back a reset (RST) packet.  It's the RST which blows
>the connection on the local machine.
>

Yes. I realised default was around 2 hours but I thought that the Solaris 2.3
`ndd' command would allow me to change this.

>>3. If I use select() and recv(), timing out the select every ten seconds
>>   and probing the client with garbage OOB data I get a connection timed
>>   out after ~2.5 minutes, *even though the connection is fine*.
>>   Why 2.5 minutes; I mean what tcp timeout parameters contribute to this 
>>   figure? Why does it timeout when the connection is OK? I thought the 
>>   client would just ack the non-inline OOB data.
>>
>
>TCP doesn't really have 'OOB' data.  Urgent data is subtly different, and
>widely mis-implemented! I don't recommend using urgent in the way you seem
>to be using it - mail me if you want more info.
>>

Using tcpdump I found that the Windows clients would only accept 10 bytes
of OOB data before they would stop acking. This is why my connection timed
out (although behaviour was different on SunOS4). I had been led to believe
that each OOB message would `overwrite' the previous one.     
If it had worked, this would have been a nice cheap solution since I wouldn't
have to change any client code.

>>4. Why don't I always get `connection reset by peer' when I reboot the PC?
>>
>>
>Same as 1, unless you close down the PC in an orderly way, which will close
>connections.
>
>>Any help is greatly appreciated.
>>
>
>Two options:  Either implement an in-band keep-alive between the clients
>and server in the TCP stream, or a separate handshake mechanism, probably
>using UDP between the clients and server.
>
>TCP keep-alives:  Code your applications (client and server) to exchange
>data regularly (a two-way handshake).  If the exchange doesn't happen when
>expected (it's usual to allow something like three 'poll' periods before you
>give up), assume the other end has gone away. This assumes you have full
>control of both ends.
>
>UDP keep-alives:  Similar idea, but without interfering with the main code;
>If your're only interested in the server knowing when the clients have
>crashed, this is far more efficient; the clients each throw a datagram
>periodically to the server.  The server calls 'recvfrom' to receive the
>datagrams, and identifies the client from its IP address.  Since UDP is
>an unreliable protocol, it's as well to give it a wider margin for error -
>say 5 missing polls before you assume it's gone, and close its session.
>
>If I read you right, what you need is for the server (Unix) to know if the
>clients (PCs) have gone away - right?  There's a third option which will tell
>you if the PC is alive - ICMP echoes, like the 'ping' program uses.  If the
>server sends ICMP echo requests to the clients, and they don't reply, then
>the client's IP stack is not there - which is as good as a dead client.  Again,
>you should allow a margin of error in case a packet gets trashed on the
>network.  One small (?) problem with this is that it needs a raw IP socket,
>which is normally only available to root.  It would be possible to run the
>poller as a separate suid process, or to start up as root, open the socket,
>and the call setuid to relinquish root privs.  The 'ping' source code from
>any of the freeBSD packages should be a good starting point for the code.
>
>The advantage of this approach is that it requires no code on the PC clients.
>I'm not sure how you'd set up the PC to send a datagram (or data in the
>TCP stream periodically); but then again, what I know about windoze could
>be summarised in about three words - "it's **** ****" (well, 3.5 :-).
>The downside is that it's probably harder to write.  There's also a race
>condition: if the PC crashes and is re-started within the poll timeout,
>the system will appear to be still there, but it may not still be an active
>user of your server.  What's more, unless your server tries to send data
>to the PC, it will not notice until the next TCP keep-alive fires.
>

Lots of good advice here. The ping sounds easy but won't tell me if a client
program crashes - only if host crashes. 

Aaron Akman <aaron@lehman.com> wrote:
>
>Regarding your TCP/IP question:
>
>I have always implemented an application-level (or you could call it
>session-level) KEEP-ALIVE protocol.  This seems to be one common way
>of solving the problem.  Basically, all messages would be of the form:
>
>	2-byte-length
>	message-type
>	message-body
>
>The message-type field would be one of APPLICATION-MESSAGE,
>ARE-YOU-ALIVE, I-AM-ALIVE.  Application messages are processed as
>always, ARE-YOU-ALIVE messages are immediately responded to, and
>I-AM-ALIVE messages are an indicator the other side is still alive.
>
>The recipe for one side of the communications is:
>
>	if (things are quiet) {
>		Start sending ARE-YOU-ALIVE requests every M seconds.
>	}
>
>	if (there is lots of traffic for now) {
>		Stop sending ARE-YOU-ALIVE requests
>		until things get quiet again.
>	}
>
>	if (APPLICATION-MESSAGE or I-AM-ALIVE
>	    not received in last N seconds) {
>		Other side has died.
>		Start trying to reconnect.
>	}
>
>Tuning M and N are important, but are localized to each communicating
>party. 
>

I'm going to have to do something like this.


Stefan Sharkansky <shark@netcom.com> wrote:
>
>In general, I can think of only 2 ways for any entity to detect that its
>peer is dead:
>
>1) is to NOT get an expected message from the peer.  So if you are using
>TCP to try to send data to someone who is not there, your kernel will retry
>a few times, and fail to get the expected acknowledgement.  Your kernel
>will then declare the peer dead, and your application returns from the
>write() with a -1.  Ignoring KEEPALIVES for now, if you're waiting to
>receive data on the TCP connection, you can't expect to detect failure
>unless the peer fails to send an expected application-level message.
>E.g. you DO need a client-server ping protocol, and for many reasons you
>want the clients to ping the server, not the other way around.  This will
>take care of situations (a) and (c).
>
>2) The second way to detect failure is for a trusted third party to
>explicitly inform you that the peer has failed.  This happens after the
>peer host has crashed and rebooted and the new incarnation of the kernel
>(the third party in this case) sends a RESET in response to received TCP
>data for a connection that no longer exists. Again, this only helps if you
>try to send to the peer.  Otherwise you could wait forever.  So you need
>the client to ping here as well.
>
>
>>2. Why doesn't keepalive seem to work? I've set it to a minute with ndd, 
>>   pulled the cable, waited and nothing. How long do you have to wait in total?
>>   Does changing the tcp driver parameters with ndd take effect immediately?
>>   (Yes, SO_KEEPALIVE option is set)
>
>"Illustrated TCP/IP" explains this quite well.  I think that the default
>keep alive interval is on the order of 2 hours on most systems.  Also, I
>think you generally need to catch SIGPIPE to learn of failure.  My personal
>opinion: KEEPALIVES are useless, use a client-ping protocol instead.
>
>>3. If I use select() and recv(), timing out the select every ten seconds
>>   and probing the client with garbage OOB data I get a connection timed
>>   out after ~2.5 minutes, *even though the connection is fine*.
>>   Why 2.5 minutes; I mean what tcp timeout parameters contribute to this 
>>   figure? Why does it timeout when the connection is OK? I thought the 
>>   client would just ack the non-inline OOB data.
>>
>
>I'm not sure how consistently OOB data is implemented across various
>systems.  Better to use ordinary inline data for the client's pings.
>
>>4. Why don't I always get `connection reset by peer' when I reboot the PC?
>
>See my (2) above.
>

Again this is full of good advice but why client->server ping and not 
server->client which sounds much easier to code?
-- 
stephen@memex.co.uk

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 15:16:54 GMT
From:      zhhi9@zh014.ubs.ubs.ch (Ueli Heuer)
To:        comp.protocols.tcp-ip
Subject:   how to setup redundant routers on a host

Hi

we would like to setup a workstation so that it can use a backup router when 
the first one fails.

we have tried to use two default routes or two specific routes but in both 
cases the host does not switch over to the backup router when we disable the 
first.

This must be a common need 

Our environment is sun with cisco routers

We do not wish to have the full routing table of the ciscos held on the 
suns.

any help gratefully appreciated 


eMail to Ulrich.z.h.h.i.9.Heuer@zhflur.ubs.ubs.ch


-- 
------------------------------------------------------------------------------
eMail:  Ulrich.z.h.h.i.9.Heuer@zhflur.ubs.ubs.ch
X.400:  /G=ULRICH/S=HEUER/I=zhhi9/OU=zhflur/O=UBS/PRMD=UBS/ADMD=ARCCOM/C=CH
------------------------------------------------------------------------------

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 94 15:43:40 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Help! Disabling Shell Access from Telnet

In article <marcbgCtvrEH.HGo@netcom.com> marcbg@esy.com writes:
>What setup do I need to use to disable the subsehll access from the 
>telnet> prompt when someone is on my system?  The user is logged on from 
>a captive account, and is automatically connected to a remote host.  
>However, if he enters the escape sequence and reaches teh telnet prompt, 
>then enteres the "!" for the subshell command, he has access to the 
>operating system.  IS there anyway of locking this out?
>
The only way I have found to do this reliably was to do a chroot to
a directory tree that only contained the commands and files I wanted
to grant access.  In you case that would include telnet (plus shared
libraries and network database files).  If you manage it just right
you can use hardlinks and avoid alot of file duplication.

>Thanks in advance!!
>
>-- 
> Marc Grant                                          
> Home: marcbg@netcom.com                             Telephone: 214-205-4593
> Office: marcbg@esy.com                                  Amateur Radio N5MEI
>              "The road to enlightment is chuck full o' potholes"


--
John A. Scott                         Data General
Phone: +1 919 248 5995                62 TW Alexander Drive
Email: scott@rtp.dg.com               Research Triangle Park, NC 27709

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 15:45:34 GMT
From:      frank@nyssa.acs.ohio-state.edu (Frank G. Fiamingo)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Help! Disabling Shell Access from Telnet

In article <marcbgCtvrEH.HGo@netcom.com>, marcbg@netcom.com (Marc B. Grant) writes:
|> What setup do I need to use to disable the subsehll access from the 
|> telnet> prompt when someone is on my system?  The user is logged on from 
|> a captive account, and is automatically connected to a remote host.  
|> However, if he enters the escape sequence and reaches teh telnet prompt, 
|> then enteres the "!" for the subshell command, he has access to the 
|> operating system.  IS there anyway of locking this out?
|> 
|> Thanks in advance!!
|> 
|> -- 
|>  Marc Grant                                          
|>  Home: marcbg@netcom.com                             Telephone: 214-205-4593
|>  Office: marcbg@esy.com                                  Amateur Radio N5MEI
|>               "The road to enlightment is chuck full o' potholes"


You can get the BSD telnet and modify it so that it won't respond
to the subshell command.

Actually, I've already done this, and a little bit more, to make
a restricted telnet version that will only connect to  hosts defined
in a table.  You can find this modified version on:
sunos-wks.acs.ohio-state.edu
as telnet.91.03.25-oasis.tar.Z.

	Hope this helps,
	Frank
-- 
-----------------------------------------------------------------------
Frank Fiamingo                    	Academic Technology Services
frank@peri.acs.ohio-state.edu		UNIX Workstation Support Leader
(614)292-7802
-----------------------------------------------------------------------

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 94 15:56:34 GMT
From:      jpcalvez@ifremer.fr (Jean Pierre Calvez)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP multicast

In article 97b@salyko.cube.net, schoenau@salyko.cube.net (Thomas Schoenauer) writes:
> I want to use UDP for multicast. Is there a common solution for that
> or must I use UDP broadcast ? Whow high are the performance costs
> of broadcast compared to multicast ?


I am just reading the RFC 1112 (Host Extensions for IP Multicasting). I am not yet
acquainted with it, but it seems to me that it has great benefit upon broadcasting,
especially when you wish to transmit data to multiple systems which are not on the
same sub-net (providing that a multicast router is available between the sub-nets).

Broadcasting would require to transmit the data over the whole set of sub-net to
reach distant systems, hence eventually disturbing sub-nets who don't care with your data. Multcasting cause the data to be transmitted only on the sub-nets where
concerned systems are connected.

About performance costs, I don't see any reason why broadcasting would be better
or worse than multicasting from the point of view of the sender.

I am also interested in the subject, and if anyone could speak from experience
and precise those ideas, this would be helpful.

Are multicast routers available ?  from which constructor ? 
Is multicast now widely supported by computers ?
How to program multicasts communication ?

Thanks


-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 15:59:02 GMT
From:      piercarl@sabi.demon.co.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: Route a subnet with same net number?

>>> On Tue, 2 Aug 1994 15:14:04 +0000, Peter@bhcnt.demon.co.uk (Peter
>>> Gross) said:

Peter> We have a local LAN with approx 600 devices all running TCP/IP.
Peter> They all have their own (class B addresses)

Peter> Now, I have recently joined the Internet, and have discussed it's
Peter> merits with the Management that be, want to join one of our
Peter> systems onto it and make the NEWS, E-Mail, etc, available to our
Peter> local users.

Peter> The idea would be to have a UNIX system (inital testing will
Peter> probably be Linux) connected to the LAN and a modem on COM1 to
Peter> our Internet feeder (ie DEMON).

If you route between your internal net and the external interfaces you
will have to get one of the corporate subscriptions from Demon, BTW. The
cheap one is strictly for a single IP address and for a single machine
on which mail and news are composed and accessed. They have ways to
monitor exceptions...

Peter>       --------
Peter>       | Unix |------COM1-------->Internet
Peter>       | Box  |
Peter>       --------
Peter>          |
Peter>          |
Peter>          |
Peter>        (===============Local TCP/IP Network===============)  
Peter>           |    |    |    |    |    |    |    |    |    |
Peter>           |    |    |    |    |    |    |    |    |    | 
Peter>           |    |    |    |    |    |    |    |    |    |
Peter>       Loads of IP Addresses (no doubt already in use in the real-world)

Peter> Does anyone know if the can be done ?

Easily. Just enable routing between interface when you make config with
Linux. :-)

OK, I was just joking. Apparently your internal class B network address
has not been reserved, so probably somebody else is using it. Then you
simply *cannot* route between the two interfaces; there cannot be any
_direct_ access from any machine on the local network to the internet.

This means that you need to install daemons on the gateway machine to
act as application level gateways.

For news this is easy; you fetch the news from the internet, and your
local users just access them on the gateway machine. For mail it is
almost equally easy; your MTA can act as a mail gateway.

BTW, in the cas eof news and mail you probably don't want to go thru
Demon; you really want to use UUCP, which is much more efficient. Dircon
seems a better choice.


For the other services is not as easy. You need specific application
level proxies, and clients that can use them. For FTP ws_ftp has the
right client side; I cannot remember which ftpd packages offer proxy
service. Try having a look around "tns.com". I wish some of the people
reading this newsgroup could advise on suitable proxy packages.

You also need to be very careful in setting up the DNS on the gateway
machine; you want to be an incomplete root server for your internal
network, but not for the internet :-).

There is some enlightening discussion in the "firewall" FAQ, and some
ideas in the O'Reilly book on TCP/IP.






-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 22:47:24 -0400
From:      gwright@connix.com (Gary Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP multicast

Thomas Schoenauer <schoenau@salyko.cube.net> wrote:
>I want to use UDP for multicast. Is there a common solution for that
>or must I use UDP broadcast ? Whow high are the performance costs
>of broadcast compared to multicast ?

IP multicasting is what you want.  RFC 1112 describes the host
requirements for IP multicasting including IGMP, the Internet Group
Management Protocol (ftp://ds.internic.net/rfc/rfc1112.txt).

Multicast wins over broadcasting.  For example, on an Ethernet a
broadcast packet is received and processed by every system on the
Ethernet.  So, an IP broadcast must be actively discarded in software
by any non-IP system.  Furthermore if the packet was a UDP datagram,
then every IP system must pass the packet to UDP where it is
demultiplexed via the port number and possibly delivered to an
application (or discarded if there was no process assoicated with
the destination port).

Any broadcast application adds to the processing load of *every*
system on the network since the broadcasts must be actively filtered.

With IP multicast, each system "joins" a multicast group and
announces that information to the network (with IGMP) and configures
the local Ethernet card to selectively receive IP multicasts.  With
an IP multicast-based application, the UDP datagram is addressed
to a multicast group (a class D IP address) and transmitted on the
Ethernet with an Ethernet multicast address.  The packet is only
received by systems that have "joined" the group (i.e., have
configured their Ethernet interface to receive the packets).

I've described IP multicasting on a single network. If your network
contains IP multicast routers the routers keep track of group
membership lists throughout the internet and will forward multicast
packets as necessary so they reach every member of the group.

The Multicast Backbone (MBONE, see ftp://venera.isi.edu/mbone/faq.txt)
is a good example of multicast applications in a WAN environment.

Other resources:
    TCP/IP Illustrated Volume 1: The Protocols, W. Richard Stevens 
    TCP/IP Illustrated Volume 2: The Implementation, Gary R. Wright 
        and W. Richard Stevens (available late 1994).

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 16:12:25 GMT
From:      ph10@cus.cam.ac.uk (Philip Hazel)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.unix.admin
Subject:   Re: Help! Disabling Shell Access from Telnet

In article <1994Aug3.154340.15369@dg-rtp.dg.com>, scott@tdc.rtp.dg.com (John Scott) writes:
|> In article <marcbgCtvrEH.HGo@netcom.com> marcbg@esy.com writes:
|> >What setup do I need to use to disable the subsehll access from the 
|> >telnet> prompt when someone is on my system?  The user is logged on from 
|> >a captive account, and is automatically connected to a remote host.  
|> >However, if he enters the escape sequence and reaches teh telnet prompt, 
|> >then enteres the "!" for the subshell command, he has access to the 
|> >operating system.  IS there anyway of locking this out?

Get the source of Telnet and remove the facility. That's what I did.

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

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      03 Aug 1994 16:24:09 GMT
From:      nagendra@csa.bu.edu (nagendra mishr)
To:        comp.protocols.tcp-ip
Subject:   finding broadcast addresses for UDP Dgrams

Hi;


	I need to find the brodcast addresses for my network.. I sort
of remember that I have to cycle through all the interfaces I have and
then check each one to see if it is a broadcast address and if so use
that one to send a broadcast on..  Can anyone tell me exactly how this
is done?  

Thanks

Nagendra
nagendra@csa.bu.edu


-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 16:33:00 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

In article <31o7hp$fqu@pentagon.io.com> flipper@pentagon.io.com (Peter
Sierant) writes: 
    
    I was actually refering not to the quoted snippet, but to rfc950, which I 
    understand to be the current rfc pertaining to IP subnet masking. As I am 
    a TCP/IP neophyte, there may be something newer that I'm unfamiliar with. 
    Can you point me to some newer documentation?
    
Not yet.  Again, router requirements is in the middle of a major overhaul.
However, RFC 950 says things like: 

    "However, we recommend that the subnet bits be contiguous and located
     as the most significant bits of the local address."

Tony

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 16:40:27 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP connection establishment

> #Here is a simple description of the problem:
> #SERVER					CLIENT
> #					send SYN
> #send SYN,ACK
> #					send ACK (this ACK is lost)
> #send SYN,ACK
> #					no answer from client
> #send SYN,ACK
> #					no answer from client
> #server closes connection without sending RST
> #					client stayes in ESTABLISHED

Enough of the theory and hypothesizing about what the RFCs say ...
there *really* is a bug here that's quite interesting.

All BSD releases prior to 4.4BSD have the following code around line
650 in tcp_input.c.  The branch to dropafterack handles a completely
duplicate ACK.  If that duplicate ACK also had the SYN flag on, the
SYN is turned off.  At that label an immediate ACK is generated and the
received segment is dropped.

       			} else
                                goto dropafterack;
                } else {
                        tcpstat.tcps_rcvpartduppack++;
                        tcpstat.tcps_rcvpartdupbyte += todrop;
                }

This worked fine except for one small point (that was discussed
on this list in June 1993, and about once a year before that):
it prevents a socket from connecting to itself (which in itself
isn't a big deal) and prevents a simultaneous connect (SYNs crossing
in the night, which the RFCs do require an implementation support).
No problem.  Here's the 4.4BSD code with the fix that allows both
simultaneous opens and self connects.

            		} else {
                                /*
                                 * Handle the case when a bound socket connects
                                 * to itself. Allow packets with a SYN and
                                 * an ACK to continue with the processing.
                                 */
                                if (todrop != 0 || (tiflags & TH_ACK) == 0)
                                        goto dropafterack;
                        }
                } else {
                        tcpstat.tcps_rcvpartduppack++;
                        tcpstat.tcps_rcvpartdupbyte += todrop;
                }

Unfortunately this "fix" proceeds to "break" the example shown at the
beginning: what happens when the 3rd segment of the three-way handshake
is lost?  In the pre-4.4 code, the immediate ACK was always generated,
but in the 4.4 code since todrop equals 0 and the ACK flag is on, the
branch to dropafterack is not made  This is to allow the code to fall
through and process the ACK in the SYN_RCVD state, which is what this
"fix" was for.  When the ACK of the SYN/ACK is lost, the receiver of
the duplicate ACK is already in the ESTABLISHED state, so the remainder
of tcp_input() is really a noop--there's no reason to generate an ACK.

I just wrote a small test program to simulate this and sure enough,
4.4BSD (and 4.4BSD-Lite) and Solaris 2.3 have this bug.  I'd bet
IRIX 5.x also has it, as that's the system that the original poster
was using, although I don't have access to IRIX.  Earlier systems
(SunOS 4.1.3, AIX 3.2.2, and the old Lachman SVR4 code) are fine--the
client retransmits the ACK when it receives the duplicate SYN/ACK.

	Rich Stevens

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 21:50:36
From:      btrent@triticom.com (Barry Trent)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Analyzers

In article <31lvqg$ibr@progress.progress.com> chandler@chatham.progress.com (Peter Chandler) writes:
>From: chandler@chatham.progress.com (Peter Chandler)
>Subject: Protocol Analyzers
>Date: 2 Aug 1994 17:29:52 GMT
>Keywords: Protocol Analyzers
 
>I am looking for a good Software protocol analyzer (under $1000.00).
>Can anyone recommend one ( make and model ).
 
>thanks,

There are several that I know of -- My company makes one called LANdecoder/e 
(for Ethernet) which retails for $945.  You won't be surprised when I tell you 
that, IMHO, it is the best of the bunch ;-) . It runs under DOS on a PC.  Be 
glad to snail-mail or fax more info.  Free demo as well, by snail-mail or from 
our BBS at 612-829-0135.

Novell's LANalyzer for Windows retails for over $1000, but is frequently
available at a discount within the price range you quoted.

Klos Technology makes one called PacketView (DOS); AG Group makes EtherPeek 
(MAC); Neon Software makes one as well (the name escapes me);  FTP Software 
makes LANWatch (DOS);  ... I'm sure there are more.

There are even free ones on the net, if you are up for that -- I've forgotten 
the names (ethload?), but I am sure that someone else will post the names 
and/or ftp sites where these are available.

Hope this helps.
+-----------------------------------------------------------+
| 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                                              |
+-----------------------------------------------------------+

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 14:31:00 +0200
From:      kaltef@theo-physik.uni-kiel.de (Roland Kaltefleiter)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In <31na0m$6pq@hopi.dtcc.edu> weave@hopi.dtcc.edu (Ken Weaverling) writes:

>(NOTE: Was not sure what was appropriate group to post this to. I scanned 
>for an existing thread and didn't find any).

You will find a thread in "alt.internet.services" about that.

>Is it just me, or am I missing something?

You are missing something, see above :-)

>The August 1st issue of {Infoworld}, front page, has a story about how 
>CIX is not going to route some packets from non-CIX members unless they 
>pay a $10K annual fee, starting November 1st.
 
>Is this just plain stupid or what?

No, its not. 

>Imagine a likely scenario. I am commercial company planning on putting up
>a Web server, gopher, etc, to offer sales lit, support, etc, to my
>customers and potential clients.  I find out that a lot of sites can't
>reach it because they are behind providers that don't shell out the $10K
>to CIX. I'd be friggin pissed and take my net business elsewhere. 
 
>The value of the "net" is its connectivity. If CIX is going to become 
>elitist, then they are hurting themselves as much as the net community in 
>general. 

Yes, you are right, if you say "The value of the "net" is its connectivity.".

But it must be payed somehow, and lines over the ocean (like to europe) are
expensive.

Now if nobody pays for that, how should that work ?

In former times there were only some NON-members. But know more and more commertial
Internet Service Providers come up, use CIX routes and do not pay for that.
And because the do not share any costs of international lines, they can offer connectivity
cheaper. So others pay for their connectivity. Do you find that all right ?

If that is only during installation, this is different, but as standard form of
business, that will not work. 

And that is, what CIX will cut down.


A


>I also find it very ironic that most of the large ftp sites, web servers, 
>etc, are on edu (and I assume non-CIX) hosts.

As far as I know, US NSF-Net is member in CIX. The german University Network "WIN" is
a member of CIX.

>Will CIX members be 
>allowed to access these, even if the reverse isn't true?  Maybe these 
>sites should start charging CIX members access fees...

Read TCP and IP routing information.
And then make a difference between providers and others.

Roland

P.S.: As I see it, your internet provider ist "sura.net". They are not small and they
should be member of CIX. (I think they are). 

-- 
Roland Kaltefleiter | OFFICE: n/a please use Papermail
                    | PRIVAT: roland@toppoint.de
In an other world in an other time to come, there won't be MS-DOS.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Aug 1994 18:15:29 GMT
From:      vinod@cse.iitb.ernet.in (Vinod G Kulkarni)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PCs as IP routers

Applied Computer Solutions (acsgen@garnet.msen.com) wrote:
: Philip Burton (philip.burton@spacebbs.com) wrote:
: : Does anyone have experience with PC-based TCP/IP packages that can do IP 
: : routing?  under DOS?  under Windows?  

One solution is to use Linux as router. (And running gated if required.)
However, it still doesn't have IPX routing. The 386 can also act as 
NFS server etc., so it is quite good if needs are limited (and saves you
a PC which would otherwise be dedicated to routing.).

Vinod


-- 
--Vinod.G.Kulkarni.              ,---------------------------------------
Research scholar,		 |"People often find it easier to be result
Dept. of CSE, IIT Bombay,        | of  the  past than the cause of the -
INDIA.  (vinod@cse.iitb.ernet.in)|___________________________- future.___

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 18:16:31 GMT
From:      dougbell@netcom.com (Douglas K. Bell)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP suite for  S P O X  ??


We are interested in putting a TCP/IP network
on SPOX hardware.

Please email me if you know anything about this.

Thanks!



----------------
DougBell@Netcom.Com


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 18:16:47 GMT
From:      shark@netcom.com (Stefan Sharkansky)
To:        comp.protocols.tcp-ip
Subject:   Re: List of UDP/TCP (Services) REQUIRED

In article <31o6m5$2c7@infa.central.susx.ac.uk> leighd@central.susx.ac.uk (Leigh Dodd) writes:
>Hi All
>	Where can I get (From the NET), a list of port numbers and function
>(brief describiction will do) of each of the udp/tcp ports in the /etc/services
>file ?.

The most recent "Assigned Numbers" RFC is 1340.

You can get a copy by anonymous FTP from ds.internic.net in
/rfc/rfc1340.txt

While you're there, you might also want to download the RFC index file,
"rfc-index.txt" in the same directory.

Stefan

--

Stefan Sharkansky
Prospero Systems Research, Inc.
USMAIL	520 Frederick St. Box 19, San Francisco, CA 94117
VOICE	(415) 731-8114		FAX  (415) 731-3395
E-MAIL	shark@netcom.COM


-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 18:48:00 GMT
From:      shark@netcom.com (Stefan Sharkansky)
To:        comp.unix.programmer,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.unix.questions
Subject:   Re: SUMMARY - Detecting client death, keepalives etc

In article <1994Aug3.144819.2528@memex.co.uk> stephen@memex.co.uk (Stephen
Marley) writes:

>>>>> Prior discussion deleted
 
>
>Again this is full of good advice but why client->server ping and not 
>server->client which sounds much easier to code?

Reasons:

1) The client has to be able to detect server failure also, so you should
implement the functionality in one place and not on both client and server.

2) Server is a critical resource.  In a large system especially, the server
should not become a bottle neck, so should minimize its overhead of
administrative tasks.

3) When using blocking TCP, the server should not be in a position to have
to block sending to one client, to avoid starving other clients.

4) For simplicity and robustness, the server should be stateless. In
keeping with reasons 1-3, the client should be the one to do all the work
to recover from a failed server, not the other way around.  If a server is
managing a scarce resource and wants to know that a client has died in
order to free that resource, it should use the "lease" method.  i.e. the
client is expected to periodically send a message to "renew" its claim on
the resource, and if the server doesn't hear from the client within a
resonable interval, the client is assumed to be gone.

The typical way that this is handled is that the client sends a ping, say,
once  a minute.  The server doesn't initiate any pings, but it does reply
to the client's ping.  The client knows that the server is still alive,
because it received an answer.   If the server doesn't reply, the client
will contact another server, or wait a while before trying the original
server.

In case the server fails to hear from the client in say, 5 minutes, , it
will assume that the client is  dead.  If there was a transient failure,
and the client wasn't dead, but was only slow or something, the server
might hear from the client after it declared the client dead.  In this case
the server either says "tough luck" or ignores the client.  In either case
the client is responsible for reestablishing service.

Stefan

--

Stefan Sharkansky
Prospero Systems Research, Inc.
USMAIL	520 Frederick St. Box 19, San Francisco, CA 94117
VOICE	(415) 731-8114		FAX  (415) 731-3395
E-MAIL	shark@netcom.COM



-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 19:10:51 GMT
From:      lwv26@chemabs.uucp (Larry W. Virden)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

Of course, according to email traffic I have had this summer, NSFnet
has been doing this since January - I suspect that CIX is just
retaliating.

I assume that the folk paying the fee are ready for the additional headaches
that rerouting of usenet, email, etc. traffic will provide?
-- 
:s Great net resources sought...
:s Larry W. Virden                 INET: lvirden@cas.org
:s Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
The task of an educator should be to irrigate the desert not clear the forest.

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 19:18:07 GMT
From:      Rahul Dhesi <dhesi@rahul.net>
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In <31na0m$6pq@hopi.dtcc.edu> weave@hopi.dtcc.edu (Ken Weaverling) writes:

>If CIX is going to become 
>elitist, then they are hurting themselves as much as the net community in 
>general. 
 
>I also find it very ironic that most of the large ftp sites, web servers, 
>etc, are on edu (and I assume non-CIX) hosts.  Will CIX members be 
>allowed to access these, even if the reverse isn't true? 

Currently, commercial sites are permitted to access most EDU sites in
the US if and only if they agree to abide by certain rules, listed in
the NSF AUP (accepted use policy).  So, in one sense, the EDU sites are
already elitist:  Merely to browse through their WWW home pages the
rest of us must agree to the AUP.  CIX members, on the other hand,
impose no such obligation on the EDU community.  Even though the CIX
was created to allow free commercial use of networks, CIX members do
not require EDU sites to be making commercial use in order to access
the home pages of CIX members.

More interestingly, if an EDU site and a CIX site wish to exchange
commercial traffic by mutual consent, the CIX site is required to pay
a hefty fee to ANS CO+RE  while the EDU site is not -- even though
both are involved in the traffic, and the traffic is bidirectional.

It's not the CIX that is being elitist.
-- 
Rahul Dhesi <dhesi@rahul.net>
also:  dhesi@cirrus.com

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 19:39:25 GMT
From:      rdmastro@jpmorgan.com (Richard Del Mastro,gov)
To:        comp.protocols.tcp-ip
Subject:   Re: interesting socket questions - expert

Path: swhittle4!rdmastro
Distribution: world
Newsgroups: comp.protocols.tcp-ip
Followup-To: 
References: <sej.775529223@interaccess>
From: rdmastro@jpmorgan.com (Richard Del Mastro,gov)
Reply-To: rdmastro@jpmorgan.com
Organization: J.P. Morgan Inc.
Subject: Re: interesting socket questions - expert
Summary: 
Keywords: 

In article 775529223@interaccess, sej@psycfrnd.interaccess.com (Stephen Johnson) writes:
>>I get "Address already in use" error.
>>I read about SO_LINGER option, and it does work, but if I use it,
>>the manual says that I will lose any data that is pending to be delivered
>>whhen close() occures.  What is the proper way to avoid this situations?
 
Actually, the option you want to set is called SO_REUSEADDR. Even though
TCP distinguishes a connection via the local *and* the foreign port, common
implementations of TCP don't allow a port number to be reused during the linger
time. By setting SO_REUSEADDR, the OS will allow the socket to be bound
to the port, and will ensure that the ensuing connection is unique.

-------

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 20:00:17 GMT
From:      hillm@ohsu.edu (Milton Hill)
To:        misc.consumers.house,comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.networking
Subject:   advice on tcp-ip cable and telephones sought

Hi - A quick question about wiring my new house:
If I go with a catagory 5 10BaseT/UTP cable to make
a small tcp/ip network can I do the following - 
The cable is 4 pair, I would like to run phone
signal over 1 pair and network over the others.
Does anyone think there would be a problem with
inter ference?

Thanks
Milt
hillm@ohsu.edu

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Aug 1994 20:10:20 GMT
From:      gnn@netcom.com (George Neville-Neil)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP FAQ


Hi Folks,

	Here is the latest TCP/IP FAQ.  Please email me with any problems.

Later,
George

Archive-name:tcp-ip/FAQ
Last-modified:  1994/08/01

Internet Protocol Frequently Asked Questions

Maintained by: George V. Neville-Neil (gnn@netcom.com)
Contributions from:
Ran Atkinson
Stephane Bortzmeyer
Phill Conrad 
Jon Kay 
William Manning
Barry Margolin 
Jim Muchow
W. Richard Stevens 
 
Version 1.4


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

	The following is a list of Frequently Asked Questions, and
their answers, for people interested in the Internet Protocols,
including TCP, UDP, ICMP and others.  Please send all additions,
corrections, complaints and kudos to the above address.  This FAQ will
be posted on or about the first of every month.

	This FAQ is available for anonymous ftp from :
ftp.netcom.com:/pub/gnn/tcp-ip.faq .  You may get it from my home page at
ftp://ftp.netcom.com/pub/gnn/gnn.html

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

Table of Contents:
Glossary
1) Are there any good books on IP?
2) Where can I find example source code for TCP/UDP/IP?
3) Are there any public domain programs to check the performance of an
IP link? 
4) Where do I find RFCs?
5) How can I detect that the other end of a TCP connection has
crashed?  Can I use "keepalives" for this?
6) Can the keepalive timeouts be configured?
7) Can I set up a gateway to the Internet that translates IP
addresses, so that I don't have to change all our internal addresses 
to an official network? 


Glossary:

I felt this should be first given the plethora of acronyms used in the
rest of this FAQ.

IP: Internet Protocol.  The lowest layer protocol defined in TCP/IP.
This is the base layer on which all other protocols mentioned herein
are built.  IP is often referred to as TCP/IP as well.

UDP: User Datagram Protocol.  This is a connectionless protocol built
on top of IP.  It does not provide any guarantees on the ordering or
delivery of messages.  This protocol is layered on top of IP.

TCP: Transmission Control Protocol.  TCP is a connection oriented
protocol that guarantees that messages are delivered in the order in
which they were sent and that all messages are delivered.  If a TCP
connection cannot deliver a message it closes the connection and
informs the entity that created it.  This protocol is layered on top
of IP.

ICMP:  Internet Control Message Protocol.  ICMP is used for
diagnostics in the network.  The Unix program, ping, uses ICMP
messages to detect the status of other hosts in the net.  ICMP
messages can either be queries (in the case of ping) or error reports,
such as when a network is unreachable.

RFC: Request For Comment.  RFCs are documents that define the
protocols used in the IP Internet.  Some are only suggestions, some
are even jokes, and others are published standards.  Several sites in
the Internet store RFCs and make them available for anonymous ftp.

SLIP:  Serial Line IP.  An implementation of IP for use over a serial
link (modem).  CSLIP is an optimized (compressed) version of SLIP that
gives better throughput.

Bandwidth:  The amount of data that can be pushed through a link in
unit time.  Usually measured in bits or bytes per second.

Latency:  The amount of time that a message spends in a network going
from point A to point B.

Jitter:  The effect seen when latency is not a constant.  That is, if
messages experience a different latencies between two points in a
network.

RPC:  Remote Procedure Call.  RPC is a method of making network access
to resource transparent to the application programmer by supplying a
"stub" routine that is called in the same way as a regular procedure
call.  The stub actually performs the call across the network to
another computer.

Marshalling:  The process of taking arbitrary data (characters,
integers, structures) and packing them up for transmission across a
network.

MBONE: A virtual network that is a Multicast backBONE.  It is still a
research prototype, but it extends through most of the core of the
Internet (including North America, Europe, and Australia).  It uses IP
Multicasting which is defined in RFC-1112.  An MBONE FAQ is available
via anonymous ftp from: ftp.isi.edu"  There are frequent broadcasts of
multimedia programs (audio and low bandwidth video) over the MBONE.


1) Are there any good books on IP?

A) Yes.  Please see the following:

Internetworking with TCP/IP Volume I
(Principles, Protocols, and Architecture)
Douglas E. Comer
Prentice Hall 1991

This volume covers all of the protocols, including IP, UDP, TCP, and
the gateway protocols.  It also includes discussions of higher level
protocols such as FTP, TELNET, and NFS.

Internetworking with TCP/IP Volume II
(Design, Implementation, and Internals)
Douglas E. Comer / David L. Stevens
Prentice Hall 1991

Discusses the implementation of the protocols and gives numerous code
examples.

Internetworking with TCP/IP Volume III (BSD Socket Version)
(Client - Server Programming and Applications)
Douglas E. Comer / David L. Stevens
Prentice Hall 1993

This book discusses programming applications that use the internet
protocols.  It includes examples of telnet, ftp clients and servers.
Discusses RPC and XDR at length.

TCP/IP Illustrated, Volume 1: The Protocols, 
W. Richard Stevens
(c) Addison-Wesley, 1994 

An excellent introduction to the entire TCP/IP protocol suite,
covering all the major protocols, plus several important applications.

Unix Network Programming
W. Richard Stevens
Prentice Hall 1990

An excellent introduction to network programming under Unix.

The Design and Implementation of the 4.3 BSD Operating System
Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, John S.
Quarterman 
Addison-Wesley 1989

Though this book is a reference for the entire operating system, the
eleventh and twelfth chapters completely explain how the networking
protocols are implemented in the kernel.


2)  Where can I find example source code for TCP/UDP/IP?

A)  Code from the Internetworking with TCP/IP Volume III is available
for anonymous ftp from:

arthur.cs.purdue.edu:/pub/dls

Code used in the Net-2 version of Berkeley Unix is available for
anonymous ftp from:

ftp.uu.net:systems/unix/bsd-sources/sys/netinet 

and

gatekeeper.dec.com:/pub/BSD/net2/sys/netinet

Code from Richard Steven's book is available on:
ftp.uu.net:/published/books/stevens.*

3)  Are there any public domain programs to check the performance of
an IP link?

A)  

TTCP:  Available for anonymous ftp from....

Host gatekeeper.dec.com

    Location: /.0/BSD/NetBSD/NetBSD-current/othersrc
      DIRECTORY dr-xr-xr-x        512  Apr  8 09:57  ttcp
    Location: /.0/BSD/NetBSD/NetBSD-current/othersrc/ttcp
           FILE -r--r--r--       3885  Nov  7 03:35  ttcp.1
           FILE -r--r--r--      19225  Nov  7 03:35  ttcp.c

Host world.std.com

    Location: /src/wuarchive/graphics/graphics/mirrors/sgi.com/sgi/src/ttcp
           FILE -r--r--r--       3885  Oct  4 1991  ttcp.1
           FILE -r--r--r--      19170  May 17 1993  ttcp.c
           FILE -r--r--r--      13033  Sep  5 1989  ttcp.c-brl

On ftp.sgi.com are netperf (from Rick Jones at HP) and nettest
(from Dave Borman at Cray).  ttcp is also availabel at ftp.sgi.com.




There is suite of Bandwidth Measuring programs from gnn@netcom.com.
Available for anonymous ftp from ftp.netcom.com in
~ftp/gnn/bwmeas-0.3.tar.Z These are several programs that meausre
bandwidth and jitter over several kinds of IPC links, including TCP
and UDP.


4) Where do I find RFCs?

A)  This is the latest info on obtaining RFCs:
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@ISI.EDU with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@ISI.EDU
        Subject: getting rfcs

        help: ways_to_get_rfcs

The response to this mail query is quite long and has been omitted.

RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET,
NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or FTP.SESQUI.NET.


Using Web, WAIS, and gopher:

Web:

http://web.nexor.co.uk/rfc-index/rfc-index-search-form.html

WAIS access by keyword:

wais://wais.cnam.fr/RFC

Excellent presentation with a full-text search too:

http://www.cis.ohio-state.edu/hypertext/information/rfc.html

With Gopher:

gopher://r2d2.jvnc.net/11/Internet%20Resources/RFC
gopher://muspin.gsfc.nasa.gov:4320/1g2go4%20ds.internic.net%2070%201%201/.ds/
.internetdocs



5) How can I detect that the other end of a TCP connection has crashed?
Can I use "keepalives" for this?

A) Detecting crashed systems over TCP/IP is difficult.  TCP doesn't require
any transmission over a connection if the application isn't sending
anything, and many of the media over which TCP/IP is used (e.g. ethernet)
don't provide a reliable way to determine whether a particular host is up.
If a server doesn't hear from a client, it could be because it has nothing
to say, some network between the server and client may be down, the server
or client's network interface may be disconnected, or the client may have
crashed.  Network failures are often temporary (a thin ethernet will appear
down while someone is adding a link to the daisy chain, and it often takes
a few minutes for new routes to stabilize when a router goes down), and TCP
connections shouldn't be dropped as a result.

Keepalives are a feature of the sockets API that requests that an empty
packet be sent periodically over an idle connection; this should evoke an
acknowledgement from the remote system if it is still up, a reset if it has
rebooted, and a timeout if it is down.  These are not normally sent until
the connection has been idle for a few hours.  The purpose isn't to detect
a crash immediately, but to keep unnecessary resources from being allocated
forever.

If more rapid detection of remote failures is required, this should be
implemented in the application protocol.  There is no standard mechanism
for this, but an example is requiring clients to send a "no-op" message
every minute or two.  An example protocol that uses this is X Display
Manager Control Protocol (XDMCP), part of the X Window System, Version 11;
the XDM server managing a session periodically sends a Sync command to the
display server, which should evoke an application-level response, and
resets the session if it doesn't get a response (this is actually an
example of a poor implementation, as a timeout can occur if another client
"grabs" the server for too long).

6) Can the keepalive timeouts be configured?

A) I know they can on many systems, but I don't know the details.

7) Can I set up a gateway to the Internet that translates IP addresses, so
that I don't have to change all our internal addresses to an official
network?

A) There's no general solution to this.  Many protocols include IP
addresses in the application-level data (FTP's "PORT" command is the most
notable), so it isn't simply a matter of translating addresses in the IP
header.  Also, if the network number(s) you're using match those assigned
to another organization, your gateway won't be able to communicate with
that organization (RFC 1597 proposes network numbers that are reserved for
private use, to avoid such conflicts, but if you're already using a
different network number this won't help you).

However, if you're willing to live with limited access to the Internet from
internal hosts, the "proxy" servers developed for firewalls can be used as
a substitute for an address-translating gateway. See the firewall FAQ.
-- 
gnn@netcom.com

Law is there to clean up etiquette's failures.
					Ms. Manners

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 00:20:25 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.dcom.cell-relay,comp.benchmarks,comp.protocols.tcp-ip
Subject:   Netperf Revision 1.9alpha Now Available

Folks,

There is a new, experimental version of netperf available via
anonymous FTP. This version includes two new test suites. The first is
Unix Domain (AF_UNIX) sockets. The second is the Fore ATM API. As
always, there are both throughput *_STREAM and latency *_RR tests.

This version is built on top of the never-really-released 1.8 version,
so it includes the BSD sockets and the DLPI tests. It also has some
code clean-up.

I have been able to test the new AF_UNIX functionality, but I have not
been able to test the Fore ATM API stuff. I have been able to compile
it. However, I have no ATM equipment at my disposal presently, but
welcome any and all bug reports. I'd also be willing to telnet into
systems to help debug things.

This revision can be retrieved with the URL:
ftp://ftp.cup.hp.com/dist/networking/benchmarks/exp/netperf-1.9alpha.tar.Z 

I would like to thank the folks at Fore for their continuing help in
putting together the Fore API tests.

happy benchmarking,
rick jones

BTW - I am still looking for feedback on switching netperf to use
POSIX signal calls. So far, the response has been underwhelming.
Unless I hear anything to the contrary soon, I'll be switching to
POSIX signal calls before 1.9 "officially" releases.

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 00:38:43 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & broadcasts on a Novell Server

In article <31nicp$8o6@hopi.dtcc.edu> weave@hopi.dtcc.edu (Ken Weaverling) writes:
>         e.  A gateway may forward a directed broadcast datagram, i.e.,
>             a datagram with the IP destination address:
>...
>         f.  A gateway is permitted to protect its connected networks by
>             discarding directed broadcast datagrams.
>
>  Sounds like maybe it's brain-damaged (as in 'e') or maybe it's being
>over-protective (as in 'f').  I'd go for the first myself.....

I can assure you it was the second. By the way, I think the next
release of the TCPIP.NLM will allow you to control whether or not such
packets are forwarded, so I guess someone agrees with you.

					don provan
					donp@novell.com

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      3 Aug 1994 23:15:46 +0100
From:      pmiles@tdc.dircon.co.uk (Peter Miles)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   scripted telnet

Can anyone point me to a version of telnet (source if poss) which 
supports scripting, a bit like comms programs for PCs do?

Basically what I need is a telnet which will automatically send a series
of commands, receive responses and send more commands based on those
responses. At the end of the script it must hand over control back to the
user (or be able to exit on error).

It would be handy if the scripted part of the sequence could be made
invisible to the user.

Please email any responses, and I'll post a summary to anyone else who is
interested.

Many thanks!

			-- Pete
-- 
Pete Miles			pmiles@dircon.co.uk
				...pipex!dircon!pmiles

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 10:54:19 -0500
From:      karl@MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In article <jcmorris.776005069@mwunix>,
Joe Morris <jcmorris@mwunix.mitre.org> wrote:
>Rahul Dhesi <dhesi@rahul.net> writes:
>
>>                                    So, in one sense, the EDU sites are
>>already elitist:  Merely to browse through their WWW home pages the
>>rest of us must agree to the AUP.  CIX members, on the other hand,
>>impose no such obligation on the EDU community.  Even though the CIX
>>was created to allow free commercial use of networks, CIX members do
>>not require EDU sites to be making commercial use in order to access
>>the home pages of CIX members.
>
>That isn't a valid comparison.  Educational facilities (at least in
>theory) are generally given numerous advantages such as tax exemptions
>in return for performing a function on behalf of the entire population.
>One of the most common restrictions that are (supposedly) placed on
>them in return is that their facilities cannot be used for commercial
>purposes; a commercial facility, on the other hand, does not get the
>benefits like tax exemption, and is not subject to the corresponding
>restrictions.

Better not tell that to all the regional networks that started out as
affiliated by, or underwritten by, those same educational institutions
(like MOST OF THEM) who sell, and have for years sold, connections to 
commercial sites.

Some of them still are affiliated in one way or another.

Yes, fair and free commercial competition.  NOT.

--
--
Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity
Modem: [+1 312 248-0900]     | (shell, PPP, SLIP, leased) in Chicagoland
Voice/Fax: [+1 312 248-8649] | 5 POPs throughout the area, all 28.8 equipped
MCSNet is a CIX Member       | Email to "info@mcs.net" for a more information
Ask about "MCSNet Rewards"   | WWW: http://www.mcs.net, gopher: gopher.mcs.net

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 03:32:36 GMT
From:      root@ga.oz.au (System Administrator)
To:        comp.unix.sys5.r4,comp.sys.m88k,comp.protocols.tcp-ip
Subject:   Configuration of gated 3.0.3 on m88k/svr4

Hi all,
	I have been attempting to port gatedR3_0_3 from Cornell to a
Motorola m88k based system running SVR4 (which I believe to be very 
close to the Unisys implementation of SVR4.)  The generic 'svr4'
configuration file is wrong in many respects that I have been able to 
identify and correct for this platform.  There are still some areas that
I am unsure about however.  If you are able to assist please e-mail
me at jbell@ga.oz.au.

(1) Kernel routing table details.
    The generic 'svr4' configuration file asserts the following options:

	KRT_RTREAD_KMEM - 4.3BSD hash based routing tables are read
	directly from kernel memory. (I have no idea whether this is true.)

	KRT_IFREAD_IOCTL - interface list is read directly from kernel
	with SIOCGIFCONF ioctl interface.  (Presumably correct as the
	getkerninfo() system call is not supported.)

	KRT_SYMBOLS_NLIST - kernel values can be read via nlist() interface.
	(This is correct.)

	KRT_RT_IOCTL - kernel routing tables manipulated via SIOCADDRT and
	SIOCDELRT ioctls. (I don't know whether this is correct.)

	KRT_LLADDR_KMEM - physical addresses of IEEE 802 devices are read 
	from kernel by assuming that an arpcom structure preceeds the ifnet.
	(I have no idea whether or not this is correct.)

(2) Kernel virtual memory access method.
    The generic 'svr4' configuration file asserts the option KVM_TYPE_OTHER
    (No kvm libraries - must read kernel info from /dev/mem)

Thanks in advance,
jbell@ga.oz.au (John Bell)

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 11:20:31 -0400
From:      manmetha@gauss.rutgers.edu (Rajesh Malhotra)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sources.wanted
Subject:   WANTED: 486 based progs for name resol, news collect, mail serv


Fellow Nett'ers,

	I am looking for programs to run on an Intel based machine to do
the following:
	1. To do the name resolution for our sub domain. This machine would
	   be our name server.
	2. To collect news from our Internet provider. This will have large
	   enough disks to hold our news and act as a news server.
	3. To collect and hold mail for non unix machines, and hence act as
	   mail server.

	Is it advisable to use the same machine to do all these tasks? What
sort of software do I need to achieve all these tasks on a 486 based machine?

	Any and all help on this matter appreciated.

Thanx,

Raj.



-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 12:59:51 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In <31qvv3$eio@terminus.apexgrp.com> dzoey@apexgrp.com (Joe Herman) writes:

>In this months CACM about the Internet, one of the papers was about
>the shortage of router table space for all the new networks.  The
>proposed solution is to get your network number from your Internet
>provider, which would allow routers to look at a piece of a network
>number and know to which provider to route it. 

Yes. This is a necessary and vital thing.

>This means, of course, that if you switch providers, you have to
>switch network numbers.

That's wrong. Please study things before badmouthing them
in public. Classless Inter-Domain Routing, or CIDR, which
is what you're referring to, favors the _longest_ match.

That means that when you move from provider A to provider B,
you can continue to use a piece of provider A's address space--
all that is necessary is for provider B to advertise a smaller
piece of it.

See RFC1519 for more information.

>I don't know what the status is of the proposal.

It is in effect, and it's the way address space is allocated
now.

>Is there a better group for this?

Not really...

--
John Hawkinson
jhawk@panix.com

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 19:47:14 -0700
From:      stevel@crl.com (Steven Lawson)
To:        alt.sources.wanted,comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Re: Wanted - C++ encapsulation of BSD socket interface

Zarathustra (jschnitz@galaxy.csc.calpoly.edu) wrote:

> I'm about to reinvent this wheel and I was wondering if some kind soul
> might save me the trouble.  I would like a freely redistributable set of
> C++ classes which encapsulate the basic functionality of TCP and UDP.
> It doesn't have to be very impressive.  If nothing turns up I'm just
> going to put together a quick and crude set, but I imagine it's been
> done far too many times before.

There is a guy at UCI, Douglas Schmidt, which I took a network programming 
class from which had these.  He even did some articles in a C++ journal 
about them.  He reads this group so maybe he'll reply to you.

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 94 08:21:25 GMT
From:      sheela@purgatory.rutgers.edu (Isis Leslie)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: PCBridge as link to SLIP/PPP provider WON'T WORK

acsgen@garnet.msen.com (Applied Computer Solutions) writes:

>Thanks for your replies.  To me, what the first poster, Laine Stump,
>describes as a bridge, sounds more like a repeater to me.

Well, pretty much that what it sounded to the rest of us too..



>I know that bridges between EtherNet and Token Ring, and EtherNet and
>broadband exist, so it makes sense to me that a bridge between EtherNet
>and SLIP could exist.  My concern being that SLIP might not be a true
>"data link" protocol, and, therefore, couldn't be plugged into a bridge.

Slip is just another network media, ablbiet one that only supports IP
though....


>The information that a host or router need not be aware of the presense
>of another router between it and the host it is sending messages to
>does renew my interest in trying PCroute (I have downloaded the docs,
>and they say that RIP can be turned off).  Routing would allow me to
>consider addtional hosts on my ethernet without having to worry about
>dumping excess trafic over the SLIP link.

Well, a bridge, in reality, is two routers. (in the way we're discussing
then here at least).  Anyway when you set up the routing tables, there
shouldn't be a problem with excess slip traffic.  Properly configured
only what is need wil go over the link.

>Are ther any IP addresses that are considered "null" - for example,
>every SunOS system I've installed has 192.9.200 as its default net
>number.

Yeah, I always wondered about that.  Anyway the following blocks
are OK as far as the INNA is concerned...

10.0.0.0	- 10.255.255.255
172.16.0.0	- 172.32.255.255
192.168.0.0	- 192.168.255.255

Anyway those are the ones you're suppossed to use for bridge links, and
networks which are _not_ attached to the Internet.  I've taken it that
you can use it for your lan addresses if you only have one host attached to
the net with a registered address (like a Sun, or a PC running Linux or
Super TCP or some other machine which can handle mulitple interface)
Can any one shed more light on this area?

Also where does Sun get 192.9.200.0 anyway?

peace-Isis

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 94 09:39:11 GMT
From:      satish@terminus.ericsson.se (Satish Popat)
To:        comp.protocols.tcp-ip
Subject:   Re: Help! Disabling Shell Access from Telnet

In article <marcbgCtvrEH.HGo@netcom.com>, marcbg@netcom.com (Marc B. Grant) writes:
|> What setup do I need to use to disable the subsehll access from the 
|> telnet> prompt when someone is on my system?  The user is logged on from 
|> a captive account, and is automatically connected to a remote host.  
|> However, if he enters the escape sequence and reaches teh telnet prompt, 
|> then enteres the "!" for the subshell command, he has access to the 
|> operating system.  IS there anyway of locking this out?
|> 
|> Thanks in advance!!
|> 
|> -- 
|>  Marc Grant                                          
|>  Home: marcbg@netcom.com                             Telephone: 214-205-4593
|>  Office: marcbg@esy.com                                  Amateur Radio N5MEI
|>               "The road to enlightment is chuck full o' potholes"

There is a SHELL environment variable which is the program that gets invoked in
response to the ! escape. This is normally set to /bin/csh in your ~/.cshrc file. 
I have found that if you change this to null (e.g. setenv SHELL '') in your .cshrc
file, this will make the shell escape, !, to fail. On my SunOS 4.1.1 system it comes 
up with "exec failed" message.

Hope this helps.


Satish

---


Satish Popat
Ericsson, England 
Tel +44 533 537534
Fax +44 533 537920


-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Aug 94 17:15:48 PDT
From:      Frank Belland <fbelland@dmewrk1.orl.mmc.com>
To:        comp.sys.sun.apps,comp.sys.hp.hpux,comp.sys.hp.apps,comp.protocols.tcp-ip
Subject:   OpenView Forum 1994 Conference Status report


Received: from dmewrk1.orl.mmc.com by orl.mmc.com (4.1/1.34.a)
	id AA22571; Thu, 4 Aug 94 15:34:49 EDT
Date: Thu,  4 Aug 94 14:13:47 PDT
From: Openview Forum <ovforum@dmewrk1.orl.mmc.com>
Subject: OpenView Forum 1994 Conference Status
To: ovforum@dmewrk1.orl.mmc.com
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-Id: <Chameleon.4.01.940804152612.ovforum@dmewrk1.orl.mmc.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

OpenView Forum 1994 Conference - The response has been so great
that we are moving the Conference program across the street to
the Orange County Convention Center. (Short walk across the 
street from the Peabody Hotel).

Over 521 Conference  attendance so far, and more coming in daily.
Last year attendance was 435.

Over 30 Showcases exhibts (last year we had 15 Showcases),
with additional space now available, since we are moving to the 
Orange County Convention Center. (If you are interested in Showcase
space call 1-800-538-6680  before close of business friday.

More tutorial space is now available, so if you wanted to take
a tutorial and were told it's full, more seating is now available.

Only a couple of rooms still available at the Peabody, but other
rooms are still available at nearby hotels. call 1-800-peabody
for details.

OPENVIEW FORUM MEMBERS' CONFERENCE

AUGUST 8-12, 1994
Peabody Hotel
Orlando, Florida


Record Turn Out for the 2nd OpenView Forum Conference.
******************************************************


SEND YOUR REGISTRATION TODAY!
Email, mail or fax your registration form to:
  
Conference Registration
OpenView Forum
P.O. Box 77046
San Francisco, CA 94107
Telephone: 1-800-538-6680
Telephone outside the U.S.: 1-415-512-0865
Fax: 1-415-512-1325
Email: amotive@mcimail.com

*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*

Make your Hotel reservations now before all the rooms are booked!!
****************************************************************** 

ACCOMMODATIONS
The 1994 OpenView Forum Members' Conference will be held at the
Peabody Hotel in Orlando, Florida. You can make your hotel
reservations directly with the hotel by calling:
                             
PHONE: 1-800-PEABODY
(Outside the U.S. 1-407-352-4000)  

FAX: 1-407-351-0073        
                 
Be sure to indicate that you are with the OpenView Forum to receive
the following conference discount:

Single/Family Occupancy  $99/night

*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*


Don't miss this year's conference, it's the largest End User
presentation with REAL WORLD End User experiences.

See current Technology and New Technology demonstrated in the
OpenView Forum High Technology Showcase.

Meet with your Peers from around the World and Share Issues.

Enter your User/Developer requirements for HP & ISV products
make your requirements known!!


Conference details below:

OPENVIEW FORUM MEMBERS' CONFERENCE

AUGUST 8-12, 1994
Peabody Hotel
Orlando, Florida

                 
LOOKING FOR ANSWERS?

You'll find them at the Second Annual OpenView Forum Members'
Conference

Join OpenView users and developers from around the world to discuss
real-world OpenView experiences. Participate in technical sessions
where you'll learn about the latest in HP OpenView technology and how
your peers are successfully  implementing HP OpenView
solutions.Listen to panel discussions on industry debates. And see
up-to-the-minute demonstrations of new and emerging OpenView
products.

Only employees of OpenView Forum member organizations are eligible to
attend the OpenView Forum Members Conference. Member organizations
can send an unlimited number of employees to the conference.

PROGRAM

SUNDAY, AUGUST 7

4:00pm-7:00pm    Conference Registration Opens

MONDAY, AUGUST 8

OPTIONAL IN-DEPTH TUTORIAL SESSIONS
The 1994 OpenView Forum Members' Conference begins and ends with a
series of in-depth tutorial sessions. Be sure to register for the
sessions of your choice using the registration form located on the
back cover of this brochure.  

7:00am-9:00pm  	Conference Registration 

7:00am-8:00am   	Continental Breakfast

8:00am-12:00am 	OPTIONAL TUTORIAL SESSIONS
                	SESSION 1: INTRODUCTION TO APPLICATION INTEGRATION
               	Extending OpenView to manage systems, users and
applications represents a very attractive payback for large
distributed computing users. Learn the basic concepts of integrating
various applications into the OpenView managed domain. Integration of
legacy and new applications will also be covered.
                	Presenter: Clayton Rote, ClearSystems, Inc.

                	SESSION 2: OPENVIEW FOR WINDOWS
                	Learn the features and functions of HP OpenView for
Windows Workgroup Node Manager.     
                	Presenter: Bill Leavy, Hewlett-Packard

              		SESSION 3: TIPS AND TECHNIQUES FOR NETWORK NODE
MANAGER
               	Get your tips from the experts. This tutorial session
focuses on information  not available from other sources. Through
user examples, learn how to apply HP OpenView to a variety of network
and system management areas, including upgrading to the latest
release of Network Node Manager 3.3, event configuration, and new
data collection techniques.
               	NOTE: This class is also offered on Friday, August
12, 1:00pm-5:00pm
               	Presenter: Network and Systems Management Division
and Professional Services Organization, Hewlett-Packard

12:00pm-1:00pm 	Lunch

1:00pm-5:00pm   	SESSION 4: INTEGRATING WITH IP DISCOVERY AND LAYOUT
               	Learn how to integrate your applications with the
current and new IP Discovery and Layout features in OpenView. Topics
will include how applications can share objects, symbols, maps, and
submaps. In addition, you will learn how to augment, or add to, the
submaps within the IPMap hierarchy.
               	Presenter: Dwight Schettler, Hewlett-Packard

                	SESSION 5: DATABASE INTEGRATION
               	Learn how to integrate different databases into the
HP OpenView environment. This session focuses on what types of
information best fit into the OpenView windows database, and what
types of information are best suited to an external database. In
addition, information will be presented on how to integrate the
information stored in the two databases so that a cohesive link
between the two databases is established.
              		Presenter: Lew Gaiter, Starfire Enterprises, Inc.
                 
               	SESSION 6: DESKTOP MANAGEMENT TASK FORCE (DMTF)
              		Keep current with the status of the Desktop
Management task Force (DMTF). During this session you'll get an
overview of DMTF, a review of the DMTF architecture, and  updates on
working groups, vendor support and products announced.
               	Presenter: John McConnell, John McConnell, Inc.

7:00pm-10:00pm  	OpenView Forum Technology Showcase and Reception
                	Meet your colleagues at a welcome reception and the
opening of the OpenView Forum Technology Showcase. See first-hand
what leading vendors are doing to support OpenView. Participating
vendors include Hewlett-Packard and their Solution Partners.

TUESDAY, AUGUST 9 
                 
7:00am-5:00pm   	Conference Registration

7:00am-8:00am 		Continental Breakfast

8:00am-9:30am  	GENERAL SESSION
               	Opening Remarks                  
               	Rick Sturm, President, OpenView Forum

                	HP OpenView Vision and Strategy                 
                	Robert Hoog, General Manager, Network and Systems
Management Division, Hewlett-Packard

                	Marketing New Ideas Within Your Organization
                	Geoffrey Moore, Geoffrey Moore Consultancy

10:00am-11:30am	PARALLEL SESSIONS
               	1.0 Data to Action: Improving LAN Service With
OpenView
                	Discover how OpenView, HP/UX scripts and SAS combine
to present network managers with meaningful information. You'll also
learn how OpenView xnmgraph turns data into information.
                	Presenter: Chris Amley, 3M Company

                	2.0 OpenView and Microsoft Windows NT
               	OpenView on Unix must be able to manage NT objects
via management protocols and through integration with the Microsoft
system management product best known as "Hermes." Learn about HP's
current and planned activities toward these objectives.
                	Presenter: Milan Hanson, Hewlett-Packard

               	3.0 Distributed Management Applications: Lessons
Learned  
               	Discover the lessons learned in the development and
deployment of several distributed management applications, including
design, implementation and operational issues.
                	Presenter: Dave Mahler, Remedy Corporation 
                 
11:30am-1:00pm  	Lunch
               	OpenView Forum Technology Showcase

1:00pm-2:30pm  	PARALLEL SESSIONS
               	4.1 Network Management Platform Approach and its
Application -- CCL/EMS
                	Review the management problems in a multi-vendor
environment and learn about the application of a new management
platform: CCL/EMS
                	Presenter: Eric Tien-Wei Chin, CCL/ITRI
               	4.2 Management of Faults and Quality of Service in
Telecom- Columbia
               	Learn about a system that captures and processes
information generated by switching systems, managing  aspects related
to the maintenance and quality of telephone service.
               	Presenters: German Pardo and Marion Nunex,
Telecom-Columbia       
    
               	5.0 Panel Discussion: How to Use Network Monitoring
and Proactive Management   
                	Listen to OpenView end-users and representatives
from the HP Network Test Division discuss network baselining, RMON
and value-added NetMetrix/LanProbe functionality, guidelines for the
deployment of LAN analyzers, and the use of standards based protocols
to provide enterprise coverage.
              		Moderator: Frank Henderson, NetPlex

               	6.1 Distributed Systems Management
                	Discuss the issues of client/server application
management from an SNMP management console, including the problems a
system manager must address to deploy a comprehensive solution for
managing databases, transaction monitors, and custom or third-party
applications.
                	Presenter: Gerard Berthet, Independence
Technologies, Inc.
                	6.2 Distribution and Scalability for HP OpenView
Through DAC OSI*NODE Integration
                	Explore architectural extensions and product
alternatives for distribution and scalability.
                	Presenter: Elizabeth Nichols Ph.D, Digital Analysis
Corporation

3:00pm-4:30pm  	PARALLEL SESSIONS
                	7.1 Designing Network Management Systems for
Usability
                	Master the primary concepts that provide the
baseline for design and development of user-interface displays for
network management.
                	Presenter: Linda Giammattei, GTE Government Systems
               	7.2 The Business Case for a Common User Interface for
UNIX and MVS Systems
                	Review Mead Data Central's business case for
utilizing a common user interface.
                	Presenter: Ted Huddle, Mead Data Central

                	8.0 Network Traffic Management with EASE: Control
Costs Today and a Plan for Tomorrow!
                	Explore the importance of network-level traffic
management and how this paradigm can be complimented by device
management and other detailed analysis tools.
               	Presenters: Kitter Nagesh and Sonia Panchen,
Hewlett-Packard

               	9.1 An Application of OpenView to the Management of
an IEEE 802.6 Telecommunications Network
               	Discover how you can use OpenView for a
telecommunications network management application.
                	Presenter: Anthony Rohde, Centre for Information
Technology Research (CiTR)
               	9.2 A Case Study Using OperationsCenter for
End-to-End Monitoring of a Warehouse Management System
               	Review a case study describing the business
situation, a computing architecture that supports the business needs,
the monitoring requirements for this computing environment, and the
OperationsCenter implementation details.
                	Presenter: Carol Hibbard, Hewlett-Packard

4:00pm-6:00pm   	OpenView Forum Technology Showcase

4:30pm-6:00pm   	Birds-of-a-Feather Sessions
                	To suggest a topic or to moderate a
Birds-of-a-Feather Session, please contact the OpenView Forum hotline
at 1- 800-538-6680, or electronically at amotive@mcimail.com.
Birds-of-a-Feather Sessions are also your opportunity to begin the
formation of Special Interest Groups and Working Groups. Session
topics will be posted daily during the conference.

6:30pm-10:00pm  	An OpenView Forum Evening at Sea World 
                	Take a break and enjoy some informal time with
conference attendees. Be our guest for an evening of fun as your
explore the many attractions Sea World offers. Food and spirits will
be served.

WEDNESDAY, AUGUST 10

7:00am-8:00am  	Continental Breakfast

8:00am-9:30am   	GENERAL SESSION
                	HP OpenView Product Updates
                	Network and Systems Management Division,
Hewlett-Packard
               
10:00am-11:30am 	PARALLEL SESSIONS
                	10.1 Case Study:  Asynchronous Transfer Mode (ATM)
Network Management  Assistant (NMA) 
               	Find out about the Network Management Assistant (NMA)
functions and how NMA was developed on the OpenView Platform.
Functions include virtual network reconfiguration, routing table cost
calculations and updates, performance management and fault
management.
                	Presenter: Wayne Fuller, Stanford Telecom
				10.2 Integrating the Management of Security, Environmental
Control and Process Control Systems with Data Network Management
				Learn all there is to know about environmental and security
management using the OpenView framework.
				Presenter: Nick Parkyn, CiTR University of Queensland

                	11.0 Application Integration with OperationsCenter
                	Learn how to integrate your application with HP's
process oriented operations and problem management solution.
                	Presenter: Georg Bock, Hewlett-Packard

                	12.0 Real World OpenView
                	Learn how to solve everyday business problems using
the HP OpenView platform as the foundation for a sophisticated network
management system.
                	Presenter: Steven Giles, Radix Technologies, Inc.

11:30am-1:00pm  	Lunch
          
                	HP OpenView Management Roundtable
                	Get the answers to all your questions!
Hewlett-Packard OpenView Management will take your questions on the
latest in OpenView technology.
         			Moderator: Rick Sturm, President, OpenView Forum

1:00pm-2:30pm   	PARALLEL SESSIONS
                	13.0 Duke Power Network Design: Management of
Critical  Elements 
                	Review Duke Power's network design, its critical
elements and how Duke Power is implementing OpenView to meet their
management requirements.
                	Presenters: Paul Edmunds and Brad Black, Duke Power
Company
     
                	14.0 New Ideas in Event Management
                	Hear about the research being undertaken by HP's
intelligent network computing laboratory in the area of management of
telecom networks, and, in particular, the research into event
management and alarm correlation.
                	Presenter: Keith Harrison, Hewlett-Packard

                	15.1 Distributed Transaction Processing in Systems
Management
                	Review the issues involved in applying DTP
technology to systems and network management.
                	Presenter: Graham Chen, Centre for Information
Technology Research (CiTR)
                	15.2 Fun with OpenView: xnmgraph
                	Take the programmer's view of xnmgraph and review
useful command-line arguments. Learn ways to generate input streams
for xnmgraph from within shell scripts and how to depict circuit
utilization and network latency.
                	Presenter: Chris Amley, 3M Company

3:00pm-4:30pm   	GENERAL SESSION
                	Requirements Update
                	Review and discuss the OpenView Forum process for
collecting and responding to vendor requirements. During this session
we will discuss OpenView Forum members' reactions to vendor responses
to the 1993 requirements submitted.
                	Moderator: Cathy Lytle, Secretary, OpenView Forum

4:00pm-7:00pm   	OpenView Forum Technology Showcase                  

4:30pm-6:30pm   	Birds-of-a-Feather Sessions

THURSDAY, AUGUST 11

7:00am-8:00am  	Continental Breakfast

8:00am-9:30am   	GENERAL SESSION
                	The Road To a Common Repository and How We Get There
                	Hear what a panel of industry experts are saying
about Common Repository.
                	Moderator: Jim Herman, Northeast Consulting
Resources, Inc.

10:00am-11:30am 	PARALLEL SESSIONS
                	16.1 Resource Management: A Transition from
Centralized to Distributed Systems
               	Find out how Legent combines mainframe and
distributed systems management tools through Paramount Performance
Manager.
                	Presenter: Craig Moore, Legent Corporation
                	16.2 A UNIX Interface for UNIX and MVS Systems
                	Learn how Mead Data Central designed and built an
infrastructure that manages systems and applications and is available
through a common interface. 
                	Presenter: Michael Pritts, Mead Data Central
                 
                	17.1 OperationsCenter/Database Monitoring
                	Hear how Client Server Technologies GmbH has
integrated the monitoring of relational databases using
OperationsCenter.
                	Presenter: Stephen Campbell, Client Server
Technologies GmbH
                	17.2 Alarm, Notification and Remote Response in the
OpenView Environment
                	Take a nuts and bolts look at alarm and notification
requirements and pitfalls. You'll explore things to consider in
processing remote inquiries, diagnostics, and corrective actions, as
well as escalation schemes and associated issues.
                	Presenter: Don Grind, Telamon

                	18.0 HP OpenView Common Platform
                	Learn about the specific details of the common
enabling platform technology that HP OpenView uses to deliver true
enterprise management, including data integration for application, a
distributed service infrastructure, common integration points and
developer enablers, and an enriched and distributed user interface.
                	Presenters: Trisha Johnson and Thom Bartz, Hewlett-
Packard

11:30am-1:00pm  	Lunch

				HP OpenView Solution Partners Roundtable
                	Find out what the Premier Solution Partners are
doing. HP OpenView Premier Solution Partners will discuss your
questions on emerging technology for the HP OpenView Framework.
                	Moderator: Frank Belland, Vice President-Operations,
OpenView Forum
                 
1:00pm-2:30pm  	PARALLEL SESSIONS
                	19.1 Remote Software Distribution
                	Explore the alternatives to developing a remote load
procedure, justification for developing the procedure, an approach
that was used in development and how this solution was implemented.
                	Presenters: Debbie Cook, US Army Information Systems
 Engineering Command, and Debbie Mayfield, The MITRE Corporation
                	19.2 Storage Management Strategy
                	Learn about the trends in enterprise management
storage requirements and how HP OpenView's storage management
strategy addresses today's evolving requirements.
                	Presenter: Reiner Lomb, Hewlett-Packard    

                	20.0 Building on Quicksand: Building a Stable
Network Environment in an Unstable World
                	Network application vendors must often develop in an
unstable environment of rapidly changing hardware, operating systems,
GUI, and network platform releases. Learn about patterns found,
impacts on network integrity, and a proposed mechanism for
inter-vendor scheduling and testing. Presenter: Tom Huibregtse,
Hewlett-Packard

               	21.1 Managing SNA Networks with OpenView: A Case
Study
                	Find out about Peregrine's OpenSNA product in use at
3M Corporation and how it helps to manage their global SNA network.
                	Presenters: Eric Olinger, Peregrine Systems, Inc.
and Wayne Bowker, 3M Information Systems and Data Processing
                	21.2 Integrated Network and Systems Management: A
Case Study
                	Learn how The MITRE Corporation addressed the
complexities of managing a large network and system infrastructure
utilizing commercial off-the-shelf (COTS) products, including
configuration management, performance management, and action request
management requirements.
                	Presenters: Andre Prive, Ronald Auer, Patrick
DeShazo, The MITRE Corporation

3:00pm-4:00pm   	CLOSING GENERAL SESSION
                	Management Standards: Successes and Failures
                	Jim Herman, Northeast Consulting Resources, Inc.

FRIDAY, AUGUST 12

                	OPTIONAL TUTORIAL SESSIONS

7:00am-8:00am   	Continental Breakfast

8:00am-12:00pm  	SESSION 7: INTRODUCTION TO SNMPv2
               	The Simple Network Management Protocol Version 2
(SNMPv2) and the corresponding SNMPv2 Framework improves and extends
the initial version of SNMP and the other components of the Internet
Standard Management Framework which include the Structure of
Management Information (SMI) and the many documents which define the
Management Information Base (MIB). As a result of these changes,
SNMPv2 is well suited for traditional network management, system
management, application management, management of legacy systems via
proxy, and for manager- to-manager communications. Learn about the
result of the evolutionary changes to the framework and protocol as
defined in the Proposed Standard, including mechanisms for
coexistence with and transition from SNMPv1. 
                	Presenter: Jeff Case, SNMP Research

               	SESSION 8: XMP/XOM API
                	Get an in-depth introduction to the X/Open XOM/XMP
API and changes introduced between XMP version 3 and version 7. XOM,
defined by X/Open, is an API used to create and manipulate abstract
data objects in support of another API. XMP, also defined by X/Open,
is an API used to provide both SNMP and CMISE network management
services. Used together, these two API are the main integration point
into OSF/DME based network management platforms.
                	Presenter: Ray Caruso, Power Play Technologies, Inc.

                	Session 9: TIPS AND TECHNIQUES FOR OPERATIONSCENTER
                	Work with the experts to learn new OperationsCenter
techniques not available from other sources. Through actual user
examples, you will learn:
                	*	Problem management for a Service Desk,
                	*	Performance management through the integration of
PerfView and OperationsCenter, and
                	*	How to resolve problems through Automated Actions.
               	Presenter: Georg Bock, Hewlett-Packard

12:00pm-1:00pm 	Lunch

1:00pm-5:00pm  	SESSION 10: TIPS AND TECHNIQUES FOR NETWORK NODE
MANAGER
                	Get your tips from the experts. This tutorial
session focuses on information  not available from other sources.
Through user examples, learn how to apply HP OpenView to a variety of
network and system management areas, including upgrading to the
latest release of Network Node Manager 3.3, event configuration, and
new data collection techniques.
               	Presenters: Network and Systems Management Division
and Professional Services Organization, Hewlett-Packard
                	NOTE: This class is also offered on Monday, August
8, 8:00am-12:00pm

                	SESSION 11: DISCOVERING HOW SNMPv2 FITS INTO
OPENVIEW
                	Find out what SNMPv2 means to OpenView. Topics will
include migration from, and co-existence with, SNMPv1 products,
security and configuration, and how SNMPv2 security will affect
auto-discovery.
                	Presenter: Brian O'Keefe, Hewlett-Packard
                    
                	SESSION 12: MANAGEMENT OF THE DISTRIBUTED COMPUTING
ENVIRONMENT
               	Learn what the OSF Distributed Computing Environment
(DCE) is, its major components, why it's important, and how to
integrate the management of DCE into HP OpenView. This tutorial
session provides an understanding of why the environment needs to be
properly designed and administered, and why an operations plan is
essential to its successful operation. 
               	Presenter: Jim Clark and Michael Slavich,
Hewlett-Packard

				NOTE: Program subject to change.

REGISTRATION
Register Before July 15 for Reduced Rates

Take advantage of the OpenView Forum Discount! Register for the
Conference and four Tutorial Sessions BEFORE July 15 and save up to
$400!

CONFERENCE FEES
Only employees of OpenView Forum member organizations are eligible to
attend the OpenView Forum Members' Conference. Member organizations
can send an unlimited number of employees to the conference.

To receive discounted rates, full payment must be received on or
before July 15, 1994. Registrations received after that date will be
accepted at the regular rate. All discounts must be taken at the time
of registration.

REFUND POLICY    
There is a $100 cancellation fee for all paid registrations. OpenView
Forum must receive a written cancellation notice no later than July
15, 1994 to receive a refund minus the cancellation fee. Refunds will
not be made after July 15, 1994.

SPECIAL NEEDS
If you have any special dietary needs or disability requirements,
please enclose a letter explaining your requirements so that
arrangements can be made.

PAYMENT INFORMATION
Registration fees can be paid only in U.S. currency by check, money
order, VISA, MasterCard or American Express. All checks must be drawn
on a U.S. bank or U.S. branch of a non-U.S. bank. Please make all
checks payable to Conference Registration.

SEND YOUR REGISTRATION TODAY!
Email, mail or fax your registration form to:
  
Conference Registration
OpenView Forum
P.O. Box 77046
San Francisco, CA 94107
Telephone: 1-800-538-6680
Telephone outside the U.S.: 1-415-512-0865
Fax: 1-415-512-1325
Email: amotive@mcimail.com

REGISTRATION FORM
First Name:

Last Name:

Title:

Company:

Mailing Address:

Telephone:

Fax:

Email:

CONFERENCE REGISTRATION
Includes proceedings and all conference events EXCEPT Tutorial
Sessions

  [   ]   $595.00   BEFORE July 15  
  [   ]   $695.00   AFTER July 15 

TUTORIAL REGISTRATION
Includes Tutorial Session and proceedings for the session(s) selected

  [   ]   $175.00   One Session 
  [   ]   $350.00   Two Sessions
  [   ]   $525.00   Three Sessions
  [   ]   $700.00   Four Sessions

OPENVIEW FORUM CONFERENCE DISCOUNT
Includes Conference Registration and FOUR Tutorial Sessions
                    
  [   ]     $995.00      BEFORE July 15  
  [   ]     $1,095.00         AFTER July 15 

YOUR REGISTRATION FEES TOTAL:       =========

PAYMENT METHOD

  [   ] Check  
  [   ] Money Order
  [   ]  VISA  
  [   ] MasterCard 
  [   ] American Express 

Card Number: 
 
Expiration Date:    /

Signature:

TUTORIAL SESSION SELECTION
Please check a maximum of four sessions: one per time allocation.

Monday, August 8, 8:00am-12:00pm
  [   ]   Session  1:	Intro to Application Integration   
  [   ]   Session  2:	OpenView for Windows
  [   ]   Session  3:	Tips & Techniques -- Network Node Manager
         
Monday, August 8, 1:00pm-5:00pm
  [   ]   Session  4:	Integrating with IP Discovery/Layout
  [   ]   Session  5:	Database Integration
  [   ]   Session  6:	DMTF

Friday, August 12, 8:00am-12:00pm
  [   ]   Session 7:	Introduction to SNMPv2
  [   ]   Session 8:	XMP/XOM API
  [   ]   Session 9:	Tips & Techniques -- OperationsCenter

Friday, August 12, 1:00pm-5:00pm
  [   ]   Session 10:	Tips & Techniques -- Network Node Manager
  [   ]   Session 11:	Discovering How SNMPv2 Fits Into OpenView
  [   ]   Session 12:	Management of DCE

ACCOMMODATIONS
The 1994 OpenView Forum Members' Conference will be held at the
Peabody Hotel in Orlando, Florida. You can make your hotel
reservations directly with the hotel by calling:
                             
PHONE: 1-800-PEABODY
(Outside the U.S. 1-407-352-4000)  

FAX: 1-407-351-0073        
                 
Be sure to indicate that you are with the OpenView Forum to receive
the following conference discount:

Single/Family Occupancy  $99/night

HOTEL RESERVATIONS MUST BE RECEIVED BY JULY 1 TO GUARANTEE THE
CONFERENCE DISCOUNT. All room rates are subject to state and local
taxes.

LOCAL TRANSPORTATION
Mears Transportation provides transportation to and from the Orlando
International Airport for $11 each way. To catch the Mears shuttle,
go to the taxi area outside of Baggage Claim.
                 



*****END OF NOTE*****   


*****NOTE NEW OPENVIEW FORUM EMA

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 11:22:04 GMT
From:      ksm@ncn.uucp (Kaare Smith)
To:        comp.protocols.tcp-ip
Subject:   NIS and C2 security

I'd like to here some opinions regarding use of NIS between C2 certified
Unix systems. Doing so will cause usernames and encrypted passwords to 
be sendt over the network.  
 
Will this be in compliance to C2? 
-- 
ksm@siemens-nixdorf.no   #
Kaare Smith              #
+47 22749500             #     R2D2

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 94 12:57:49 GMT
From:      jcmorris@mwunix.mitre.org (Joe Morris)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

Rahul Dhesi <dhesi@rahul.net> writes:

>Currently, commercial sites are permitted to access most EDU sites in
>the US if and only if they agree to abide by certain rules, listed in
>the NSF AUP (accepted use policy).

Like our favorite Phoenix law firm?  I don't recall hearing any 
users from .edu sites complaining that they didn't get the Green
Card spam.

>                                    So, in one sense, the EDU sites are
>already elitist:  Merely to browse through their WWW home pages the
>rest of us must agree to the AUP.  CIX members, on the other hand,
>impose no such obligation on the EDU community.  Even though the CIX
>was created to allow free commercial use of networks, CIX members do
>not require EDU sites to be making commercial use in order to access
>the home pages of CIX members.

That isn't a valid comparison.  Educational facilities (at least in
theory) are generally given numerous advantages such as tax exemptions
in return for performing a function on behalf of the entire population.
One of the most common restrictions that are (supposedly) placed on
them in return is that their facilities cannot be used for commercial
purposes; a commercial facility, on the other hand, does not get the
benefits like tax exemption, and is not subject to the corresponding
restrictions.

(Don't get me on my soapbox about "amateur" sports being in control
of university policy...)

>More interestingly, if an EDU site and a CIX site wish to exchange
>commercial traffic by mutual consent, the CIX site is required to pay
>a hefty fee to ANS CO+RE  while the EDU site is not -- even though
>both are involved in the traffic, and the traffic is bidirectional.

You're right that there are inconsistencies, but they aren't without
some logic.  The communications world is still far too new for issues
like this one to be finally resolved.

Joe Morris / MITRE / my opinions only

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 13:04:54 GMT
From:      longyear@netcom.com (Al Longyear)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet

pmiles@tdc.dircon.co.uk (Peter Miles) writes:

>Can anyone point me to a version of telnet (source if poss) which 
>supports scripting, a bit like comms programs for PCs do?

CKERMIT 5A(189)

located on kermit.columbia.edu in the directory /kermit/b.
-- 
Al Longyear           longyear@netcom.com

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 22:24:35 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.protocols.tcp-ip
Subject:   CRC and other Questions

 Here are a few random questions that have arisen during a project I am
 working on:
 
 Does the size of a CRC depend on how much data it is being computed
 from?
 
 Is the CRC in an ethernet frame computed on the entire frame, including
 the header, or merely on the data?  What about higher level protocols,
 like IP?
 
 How can a minimum ethernet frame size be specified that is larger than
 the size of the header alone?  Doesn't this prohibit people from sending
 a frame with only one or two bytes of data?
 
 If my code is going to be turned into a TSR (it will be outsourced for
 this purpose later), is it okay for me to use callocs or mallocs?
 
 Thanks a lot for your help.
 
 --Mike
 


-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 02:10:37 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sources.wanted
Subject:   Re: WANTED: 486 based progs for name resol, news collect, mail serv

In article <31r0vv$2iu@gauss.rutgers.edu>, manmetha@gauss.rutgers.edu
 (Rajesh Malhotra) wrote:
>I am looking for programs to run on an Intel based machine to do
>the following:
>1. To do the name resolution for our sub domain. This machine would
>   be our name server.
>2. To collect news from our Internet provider. This will have large
>   enough disks to hold our news and act as a news server.
>3. To collect and hold mail for non unix machines, and hence act as
>   mail server.
>
>Is it advisable to use the same machine to do all these tasks?

Yes, definitely.

>What sort of software do I need to achieve all these tasks on a 486
>based machine?

We use BSDI for all of this (and much more!) and love it.  A decently
configured 486 actually has quite a lot of horsepower if you have an
OS that can leverage it.  The last time I checked, BSDI cost ~US$500,
and for another ~US$500 you could get its source code as well (very
useful for self-maintenence).  Technical support is also great and
relatively inexpensive.  Contact 1-800-800-4BSD for more details.

On the other hand, if you are just looking for a *DOS* program...
No comments. :-)

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"Packet Driver, WinSock & TCP/IP CD-ROM" product information:
{gopher,www,ftp}.CDPublishing.com or <info@CDPublishing.com>


-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 15:02:59 GMT
From:      dzoey@apexgrp.com (Joe Herman)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In <31na0m$6pq@hopi.dtcc.edu>, weave@hopi.dtcc.edu (Ken Weaverling) writes:
>Imagine a likely scenario. I am commercial company planning on putting up
>a Web server, gopher, etc, to offer sales lit, support, etc, to my
>customers and potential clients.  I find out that a lot of sites can't
>reach it because they are behind providers that don't shell out the $10K
>to CIX. I'd be friggin pissed and take my net business elsewhere.

In this months CACM about the Internet, one of the papers was about
the shortage of router table space for all the new networks.  The
proposed solution is to get your network number from your Internet
provider, which would allow routers to look at a piece of a network
number and know to which provider to route it.  This means, of
course, that if you switch providers, you have to switch network
numbers.  What a boon to providers!  Once an orginization has signed
up, they'd be captive to that provider unless they wanted to renumber
all their hosts!  Yeah, it would make routing easier, but the cost....

I don't know what the status is of the proposal.  Is there a better
group for this?


Joe Herman
dzoey@apexgrp.com
--
Everything is wonderful until you know something about it.


-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 15:03:40 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP multicast

RFF 1112 discusses Multicast IP over ethernet and the use of the
MAC Multicast addresses. Has any work been done on Token Ring
networks? The equivalent to Multicast there is called Groups but
I have received several warnings that most devices can't handle 
MAC Group addressing. Should I just use the C000 FFFF FFFF broadcast
address? Inquiring minds want to know.

Mark

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

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 15:18:47 GMT
From:      balld@gibbs.oit.unc.edu (Donald the Serene)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet

pmiles@tdc.dircon.co.uk (Peter Miles) writes:
>Can anyone point me to a version of telnet (source if poss) which 
>supports scripting, a bit like comms programs for PCs do?

Try tintin++  - it's a mud client, but it works very nicely as a telnet 
interface; it's more like a mini-programming language than anything 
else.  Can't remember where it is offhand, try archie.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-Donald A. Ball Jr., Dept. of Psych., UNC, Chapel Hill, NC 27599-3270=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      04 Aug 1994 16:11:45 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: are there any generic addresses?

In article <pdhCty3B4.BDv@netcom.com> pdh@netcom.com (P D H) writes:

   Are there any generic addresses?  What I am thinking of here is a set of
   addresses which have been set aside to never appear on the open internet
   but can be used by any organization on its own internal-only networks
   for purposes not needing to go outside.  One advantage of this is that
   this same addresses can be duplicated in each organization.

   Of course I could just "steal" any address.  But I would want to make
   these "stolen" addresses are not routed out to the open network and
   there may well be machines in a "common area" that wish to communicate
   with both the open internet as well as the isolated network.

   The purpose of "stealing" addresses would be to get more addresses
   without having to acquire more of the address space needlessly since
   much of the network would be isolated.  It just seems to me that if
   some addresses were set aside for this it would be easier to deal with.

There's an informational RFC to do this.  Bunches and bunches of
people had an [a]rousing discussion of this at the last Interop.  At
the end of it, a Chrysler person (not Bob Moscowitz) stood up and said
"You guys are just wasting your breath.  We're going to grab a bunch
of IP addresses and you can't stop us.  If you want to cooperate, you
can, but in the end our business has to go on, and we're using TCP/IP
so we need addresses".  He was pretty pissed.  I tried to convince him
that it was just a bunch of old hands having fun arguing over a fairly
pedantic issue, but it didn't work.  He was way unhappy.  I think Bob
managed to calm him down, though.

--
-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 16:18:44 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: What are "sider" IP numbers?

jantypas@ccnet.com (John Antypas) wrote {
    Recently, while shopping for an IP provider for a client, a vendor
    noted that the use of "sider" IP numbers was better because of the
    crunch on address space.
}

John Hawkinson <jhawk@panix.com> wrote {
    That's CIDR, prounounced <cider>. It means a SUPERNET, or group of
    small (C or B -class, usually) nets that are advertised in one chunk.
    CIDR stands for Classless Inter-domain Routing. See RFC1519.
}

   Calling them "better" seems unusual.  Indeed there is an IP
   address space crunch (mostly due to very-sub-optimal allocation
   in the past [e.g., 16 million addresses for Stanford U]),
   so a CIDR block is all most people are likely to get these days.

   So, where in the past a site with a few hundred hosts
   might have gotten a class-B address like 128.128.*.*
   now they might get a block of contiguous class-C's like
   222.222.0.* thru 222.222.3.*

   This conserves address space, and because the addresses
   are contiguous (and in power-of-2 blocks), modern routers
   can use just one route for all of them together (which
   helps the other major IP growing pain, # of routes).


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

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 94 16:39:15 GMT
From:      naran@fraser.sfu.ca (Travers Naran)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

weave@hopi.dtcc.edu (Ken Weaverling) writes:

>(NOTE: Was not sure what was appropriate group to post this to. I scanned 
>for an existing thread and didn't find any).
 
>Is it just me, or am I missing something?
 
>The August 1st issue of {Infoworld}, front page, has a story about how 
>CIX is not going to route some packets from non-CIX members unless they 
>pay a $10K annual fee, starting November 1st.
 
>Is this just plain stupid or what?
 
>Imagine a likely scenario. I am commercial company planning on putting up
>a Web server, gopher, etc, to offer sales lit, support, etc, to my
>customers and potential clients.  I find out that a lot of sites can't
>reach it because they are behind providers that don't shell out the $10K
>to CIX. I'd be friggin pissed and take my net business elsewhere. 

So you would set-up a somewhat permenant connection to the Internet via
CompuServe?  Why!?  There are many lower cost providers in North America.  In
fact, several companies (and even a few research networks) are offering
low-cost Internetn connections for corporation and other businesses.

>The value of the "net" is its connectivity. If CIX is going to become 
>elitist, then they are hurting themselves as much as the net community in 
>general. 

I don't think they are elitist, just trying to make a buck (which is their
right).  I suspect the $10k connection charge is a little more complicated than
that.  But the thing is, there is competition for Internet provider services
and CompuServe won't be trying that route for very long.

>I also find it very ironic that most of the large ftp sites, web servers, 
>etc, are on edu (and I assume non-CIX) hosts.  Will CIX members be 
>allowed to access these, even if the reverse isn't true?  Maybe these 
>sites should start charging CIX members access fees...
 
>This could get real ugly.

You said that right!  But if we all keep our heads and just ignore CIX if they
continue the activities you describe above, they won't survive long.  But I
suspect most non CIX users will tolerate CompuSpend's activities.


>-- 
>Ken Weaverling          weave@dtcc.edu |*|  Wilmington: +1 302 573-5460
>    Manager of Computer Services       |*|     Stanton: +1 302 454-3978
>   Stanton/Wilmington Campuses of      |*|       WHOIS: KJW
>Delaware Technical & Community College |*|
-- 

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 23:31:42 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In <31rutp$6mh@news.iastate.edu> john@iastate.edu (John Hascall) writes:

>}Yes. This is a necessary and vital thing.
 
>   Not necessarily -- geographical routing hierarchy is one alternative.

It is a necessary and vital thing in today's Internet. It's a solution
that works and is being used. Geographical routing is in NO way practical
in today's Internet, and while it MAY be with IP6, I really, really,
doubt it.

>}That means that when you move from provider A to provider B,
>}you can continue to use a piece of provider A's address space--
>}all that is necessary is for provider B to advertise a smaller
>}piece of it.
 
>    And what exactly would be the incentive for provider A,
>    whom you just dumped, to allow you to keep their addresses?

That none of provider A's customers would sign up with provider A
if provider A did have such policies.

Additionally, all significant (can we say, clueful?) providers
do this today.

Ideally, you should renumber eventually, anyway, to avoid the extra
route in the routing tables. At some point, with the evolution of
DHCP and IP6 renumbering will become far less painful than it is today.

Additionally, if you have ``your own'' network routed by provider
A, and you switch to provider B, Merit, who manages the NSFnet backbone,
will refuse to change their routing of ``your'' net from A to B
without acknowledgement/agreement from both B AND A.

This means that A can lock you out whether you get a net from them
or from the NIC.

--
John Hawkinson
jhawk@panix.com

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 16:55:42 GMT
From:      Rahul Dhesi <dhesi@rahul.net>
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In <jcmorris.776005069@mwunix> jcmorris@mwunix.mitre.org (Joe Morris) writes:

>You're right that there are inconsistencies, but they aren't without
>some logic.  The communications world is still far too new for issues
>like this one to be finally resolved.

This is precisely why accusations of elitism, which I was countering,
are premature at this stage of the game.  For every brickbat thrown
against the CIX it's easily possible to find some counter-brikbats.
Too many glass houses...and too many people (especially in the EDU
sites) not realizing they are living in them.
-- 
Rahul Dhesi <dhesi@rahul.net>
also:  dhesi@cirrus.com

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 17:16:24 GMT
From:      p_quinn@ECE.Concordia.CA (Paul Quinn)
To:        comp.protocols.tcp-ip
Subject:   FTP'able Protocol analysers


Recently I saw someone's post concerning protocol analysers.  The postee
mentioned that there were some availible for FTP.  Can anyone
tell me about some sites to get TCP/IP and/or IPX analysers?


--
________
Paul Quinn
p_quinn@ece.concordia.ca
Computer Science: Systems Architecture
Concordia University
Montreal, QC, CANADA
--------

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 17:19:47 GMT
From:      acsgen@garnet.msen.com (Applied Computer Solutions)
To:        comp.protocols.tcp-ip
Subject:   Re: Route a subnet with same net number?

Piercarlo Grandi (piercarl@sabi.demon.co.uk) wrote:
[...]
: OK, I was just joking. Apparently your internal class B network address
: has not been reserved, so probably somebody else is using it. Then you
: simply *cannot* route between the two interfaces; there cannot be any
: _direct_ access from any machine on the local network to the internet.
 
: This means that you need to install daemons on the gateway machine to
: act as application level gateways.

For a general purpose application level gateway, try subscribing to
the SOCKS mail list.  The address is: socks-request@inoc.dl.nec.com


-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 17:34:45 GMT
From:      acsgen@garnet.msen.com (Applied Computer Solutions)
To:        comp.protocols.tcp-ip
Subject:   Re: tunneling

Eric L Patterson (electro@engg.ksu.edu) wrote:
: Hi.  Does anyone have any information on tcp "tunneling"?
: I have a slip connection to our campus, and a small network
: at home.  However, our slip admin won't let the slip router
: run rip (allowing me to route packets for any of my machines
: at home thru the slip connection).  If i try to route an ip
: other than that of the actual slip ip, the slip router
: bounces them back.  Is there a way to encapsulate and
: de/encapsulate them at either end of the slip line?
: Thanks

Perhaps you could run an application level gateway like SOCKS
on your "main" host.  Your other hosts would then run SOCKS-ified
clients instead of the regular ones.  Try subscribing to the
SOCKS mail list.  The address is: socks-request@inoc.dl.nec.com

Ron Wilson

(Of course, if your SLIP host is using KA9Q, I'm not sure what
 to do.  Maybe you can cook up a pair of applications: one that
 you would log into your account on one of the school hosts and
 the other "plugged" into KA9Q using the TELUNIX pipe driver
 feature.  The pair could relay TCP traffic over the SLIP link.
 You might be able to modify the source to the SOCKS server
 to do this.  Good luck!)

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 17:44:52 GMT
From:      acsgen@garnet.msen.com (Applied Computer Solutions)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address for a local network?

Leigh Hart (hart@apanix.apana.org.au) wrote:
: tzs@u.washington.edu (Tim Smith) writes:
: >I'm going to be connecting a Mac and a PC together via ethernet.  They
: >will be the only things on the ethernet, and shall communicate via
 [...]
: >However, there is a slight complication.  These machings aren't quite
: >isolated.  The Mac occassionally establishes a SLIP connection over a
: >modem to a commercial SLIP provider so that it can fetch news from an
 [...]
: >In such an environment, how should I obtain IP addresses for use on my
: >ethernet?  Do I have to obtain an offical network number, or is there
: >something "safe" I can use?
: Save yourself heartache in the future - get yourself an official class C
: network number (in which you can use any host number you like for as many
: computers as you like - up to 254 hosts)) and ask your commercial provider
: to use that network address for your connections with them.

Another possiblity: For your internal network, use addresses out of one
the IP address blocks recently reserved for privite networks (see RFC1597).
You could then run, on your SLIP host, an application level gateway (such
as SOCKS (socks-request@inoc.dl.nec.com)) to allow your other machine(s)
to access InterNet services.

BTW,FYI: the priveta blocks are:
           10.x.x.x
           172.16.x.x through 172.31.x.x
   and     192.168.x.x

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 18:04:10 GMT
From:      acsgen@garnet.msen.com (Applied Computer Solutions)
To:        comp.protocols.tcp-ip
Subject:   Re: are there any generic addresses?

P D H (pdh@netcom.com) wrote:
: Are there any generic addresses?  What I am thinking of here is a set of
: addresses which have been set aside to never appear on the open internet
: but can be used by any organization on its own internal-only networks
: for purposes not needing to go outside.  One advantage of this is that
: this same addresses can be duplicated in each organization.

Yes.  See RFC1597.

According to RFC1597, the blocks reserved for private networks are:

     10.x.x.x
     172.16.x.x through 172.31.x.x
and  192.168.x.x

Ron Wilson, rwilson@vsa.com

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 18:29:26 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip
Subject:   Re: multicast file transfer?

Matthew Hannigan <matth@extro.ucc.su.OZ.AU> wrote:
>
>Is there a way of doing multicast file transfer?
>I know of an application which would benefit greatly
>from such a beast.
>
>If there is, I would appreciate any pointers to
>the standards, and any implementation.
>
>Also comments on the maturity of the standard and
>quality of the implementation, if they exist.

There are several RFCs about multicast. The main problem is
that few vendors provide the OS support. Until this support is
universally available, it is useful if applications have a
fall-back mode that does unicast or broadcast if needed. 

Perhaps you missed the post I made a month ago?

Here are the key points:

steve@ecf.toronto.edu (Steve Kotsopoulos) wrote:
> Newsgroups: comp.protocols.tcp-ip,comp.os.misc
> Subject: Call for beta testers - Adaptive File Distribution Protocol (AFDP)
> Keywords: group communication, multicast, publishing
> Date: Sat, 9 Jul 1994 00:39:22 GMT

The Adaptive File Distribution Protocol (AFDP) addresses the need for
efficient and reliable group communication.

The protocol is built on top of UDP, and uses a rate-based flow control
mechanism to provide efficient and reliable file distribution.  AFDP
uses the publishing metaphor: any machine receiving files is called a
subscriber and any machine sending files is called a publisher.  One
special subscriber is designated as the secretary; this machine is
responsible for managing the group membership and authorizing publishers.
AFDP dynamically selects between 3 different transfer modes: unicast,
multicast (on hosts that support it), and broadcast.

You can call AFDP from any of your applications, or just use the existing
file transfer mechanisms of AFDP.

AFDP is not yet ready for public release, but we are looking for a group
of beta-testers who are familiar with network programming.  If you do not
fit in this category, please wait for the public release of AFDP. 

If you would like to beta-test AFDP, contact afdp@ecf.toronto.edu.
-- 
Steve Kotsopoulos  P.Eng.                         steve@ecf.toronto.edu
Systems Analyst,  Engineering Computing Facility, University of Toronto

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 19:11:40 GMT
From:      mhyman@netcom.com (Mike Hyman)
To:        comp.protocols.tcp-ip
Subject:   Sun <-> AS/400


Has anyone had any experience with connecting Sun SPARC systems
running Solaris 2.3(+patches) to an AS/400 running their (IBM's)
TCP/IP implementation.

We might be doing just this and I am looking for any input
in the following areas:

1. Standard TCP utilities like rcp, ping, etc. Do they work the same?

2. NIS/NIS+ do these exist on the AS/400 and can the AS/400 be
part of a specific domain, with a master server onSolaris?

3. How does NFS perform, we are looking at transferring up to
2GB of data nightly with NFS, am I crazy??

4. EBCDIC to ASCII issues. When doing file transfers are the file
contents translated properly.

5. E-Mail. Does the AS/400 handle SMPT e-mail at all??

6. FDDI. We will be connecting the Sun and AS/400 together over
FDDI, is this too new to work properly, again any issues??

Thanks in advance for any and all information. I will post 
a summary of responses once I get them.

...Mike Hyman

Please respond to: mhyman@netcom.com

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 19:31:11 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: NNStat, anything better?

In article <319819$bp9@dancer.ca.sandia.gov>,
Phil Cox x41211 <pcc@ssds.com> wrote:
>I am curently using NNStat 3.0, and was wondering if there were any
>better tools out on the net for doing network analysis? If not, is 3.0
>the latest for NNStat? 

I contacted the authors, who pointed me at the latest release.
You can find version 3.2 at ftp.isi.edu:pub/braden/NNStat.tar.Z
-- 
Steve Kotsopoulos  P.Eng.                         steve@ecf.toronto.edu
Systems Analyst,  Engineering Computing Facility, University of Toronto

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 19:49:29 GMT
From:      manuel@crt0.crt.umontreal.ca (Jose Manuel Pires 514-340-6046)
To:        comp.protocols.tcp-ip
Subject:   Problem: child keeps reading the same message on a socket.


Hi,

here's a short description of what I'm doing.

I have two programs.  The first one (let's call it server) starts the second
one (client) on N hosts and then listens to a predefined port for the replies.
After the accept() call the server forks() and closes the socket returned by
accept().  The child closes the listen socket and gathers data from the
client. (I use SOCK_STREAM sockets all the time.)

Questions:

1) Sometimes, one or more of the children, will continually receive the
same message in an apparently endless loop.  How can this be?  Each client
can only send 3 messages:  - I'm here.
                           - I'm starting to work.
                           - I'm finished.
How can this cause havoc on the child's socket?

2) How can I keep the server's listen socket from being overflowded?

3) Is it safe if a client has the time to do his work, tell the server, do
a shutdown() and a close() on the socket _before_ the server had time to
reach the accept() call?  (The total number of messages is < SOMAXCONN.)

JMP

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 20:34:08 GMT
From:      klos@mv.mv.com (Patrick Klos)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol Analyzers

In article <31lvqg$ibr@progress.progress.com>,
Peter Chandler <chandler@chatham.progress.com> wrote:
>I am looking for a good Software protocol analyzer (under $1000.00).
>Can anyone recommend one ( make and model ).
>
>thanks,
>
>Peter Chandler.

We (Klos Technologies, Inc.) have a PC-based product called PacketView that
goes for $299 and can capture and decode network traffic on ethernet, token-
ring and ARCNET networks.  PacketView supports IPX/SPX/NCP, TCP/UDP/IP, VINES
IP and a few other protocols.  It has capture and display filtering, good 
symbolic support, and allows you to write your own custom protocol decoders
(should the need arise).  A demo version of PacketView is available via
anonymous FTP at mv.mv.com:pub/users/klos/pvdemo.zip or by calling our BBS at
(603) 429-0032.

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

Sincerely,

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

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Aug 1994 21:35:35 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In article <31qvv3$eio@terminus.apexgrp.com> dzoey@apexgrp.com (Joe Herman) writes:
> ...
>proposed solution is to get your network number from your Internet
>provider, which would allow routers to look at a piece of a network
>number and know to which provider to route it. ...
 
>I don't know what the status is of the proposal.  Is there a better
>group for this?

That topic as well as CIX fees, and CIX route filtering are beaten to
death every few weeks in the IETF big-internet mailing list and the
com-priv mailing list.

Com-priv@psi.com is forwarded (perhaps unidirectionally) into the
csn.ml.com-priv newsgroup.

Don't complain if the com-priv people don't act upon requests in less
than a day or two.  I'm probably being optimistic to think that this
note won't trigger too many silly "subscribe" messages to com-priv
instead of com-priv-request@psi.com.

Don't ask me where to subscribe to B-I; those who won't cause hassles
will find it by themselves.  The converse is not true, but maybe some
of those who would otherwise send bursts of "subscribe" and "unsubscribe"
messages to the wrong address won't find it.


Vernon Schryver    vjs@rhyolite.com

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 22:32:25 GMT
From:      grouch@interaccess (Ray Moran)
To:        comp.protocols.tcp-ip
Subject:   Wanted : TCP/IP for Motorola VME System

I am looking for TCP/IP to run on a Motorola VME system (w/ a 68030 chip) 
running System V/68k. Any suggestions or ideas as to something that may 
run on this system would be greatly appreciated.

Thanks,

   Ray Moran

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 22:45:00 GMT
From:      dst@u.washington.edu (Trif)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In article <naran.776018355@sfu.ca>, Travers Naran <naran@fraser.sfu.ca> wrote:
>So you would set-up a somewhat permenant connection to the Internet via
>CompuServe?  Why!?  There are many lower cost providers in North America.  In
>fact, several companies (and even a few research networks) are offering
>low-cost Internetn connections for corporation and other businesses.

Note that CIX != CompuServe, though the mistake is understandable since
CompuServe goes by the acronym CIS.


-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 1994 23:51:21 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

John Hawkinson <jhawk@panix.com> wrote:
}dzoey@apexgrp.com (Joe Herman) writes:
}>proposed solution is to get your network number from your Internet
}>provider, which would allow routers to look at a piece of a network
}>number and know to which provider to route it. 
 
}Yes. This is a necessary and vital thing.

   Not necessarily -- geographical routing hierarchy is one alternative.

}>This means, of course, that if you switch providers, you have to
}>switch network numbers.
 
}That means that when you move from provider A to provider B,
}you can continue to use a piece of provider A's address space--
}all that is necessary is for provider B to advertise a smaller
}piece of it.

    And what exactly would be the incentive for provider A,
    whom you just dumped, to allow you to keep their addresses?

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

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Aug 94 11:41:09 -0700 (PDT)
From:      Troi_Eisler@mindlink.bc.ca (Troi Eisler)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun <-> AS/400

We are doing some of the things you ask about.  Currently NFS is not
available on the AS400 side as far as I know (but I have heard roomers).
We transfer files using ftp in batch from our Suns to the AS400.  It works
very well.  Quick and translation to and from ASCII is excellent.  We have
not tried DNS but there are facilities on the AS400 to configure it.  How
well it works I don't know.  The VT100 telnet from Sun to AS400 works very
well.  I use it a lot.  I wish I could say the same for the other way
around, at least on OS400 V2R2.  The AS400 Telnet client's screen is
redrawn far too often and is very blocky/jerky.  I am in the process of
moving to OS400 V2R3 as I write and am hoping that they have improved this
feature.

I would be interested to hear how you make out and how and what you are
doing with your connection.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Aug 94 00:11:50 GMT
From:      jschnitz@galaxy.csc.calpoly.edu (Zarathustra)
To:        alt.sources.wanted,comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Wanted - C++ encapsulation of BSD socket interface


I'm about to reinvent this wheel and I was wondering if some kind soul
might save me the trouble.  I would like a freely redistributable set of
C++ classes which encapsulate the basic functionality of TCP and UDP.
It doesn't have to be very impressive.  If nothing turns up I'm just
going to put together a quick and crude set, but I imagine it's been
done far too many times before.

thanks,
jef
-- 
When a cat is dropped it always lands on its feet.
When toast is dropped it always lands butter-side down.
 I propose to strap buttered toast to the back of a cat;
 when dropped the two will hover, spinning, inches above the ground.

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 01:04:41 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: NNStat, anything better?

In article <Cu0zK0.8DI@ecf.toronto.edu> steve@ecf.toronto.edu (Steve Kotsopoulos) writes:
>>I am curently using NNStat 3.0, and was wondering if there were any
>>better tools out on the net for doing network analysis? If not, is 3.0
>>the latest for NNStat? 
>
>I contacted the authors, who pointed me at the latest release.
>You can find version 3.2 at ftp.isi.edu:pub/braden/NNStat.tar.Z

Actually, a later version that has been available for about 9 months;
it's an "unofficial" release but it has a few bug fixes, new features,
etc.  Try
	gatekeeper.dec.com/pub/DEC/net/NNStat_3.3beta.tar.Z

-Jeff

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 1994 01:20:01 GMT
From:      jparadis@courrier.usherb.ca (JParadis)
To:        comp.protocols.tcp-ip
Subject:   A good idea for internet developer's !

I would like to see a client server product that could give the
geographical
location of an I.P. addresse. And it would be great to find it for
Macintosh,
since i have fall down the apple basket for 10 years now...
If it already exist let me know...
Enter 132.210.XXX.XXX on your client, server reply
Sherbrooke,Quebec,Canada
Canada is only for a indeterminated time ... Countdown is already
started ...
If you want to put time on it and make money whit it... Don't forget
your idea's lighter...jparadis@courrier.usherb.ca  
I'm to buzy for this kind of work now... 

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 10:28:13 -0500
From:      plarkin@iphase.com (Patrick Larkin Jr)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet


In article <longyearCu0Ho6.4I0@netcom.com>, longyear@netcom.com (Al Longyear) writes:
> >Can anyone point me to a version of telnet (source if poss) which 
> >supports scripting, a bit like comms programs for PCs do?
> 
> CKERMIT 5A(189)
> 
Assuming you dont need to get too complex, you COULD use something
like:

(sleep 10
 echo "loginid-goes-here"
 sleep 3
 echo "password-goes-here"
 sleep 10
 echo "command-goes-here"
 sleep 2
 echo "more-commands"
 # and so on
 echo "exit" ) | telnet sitename.domain.domain

but ensure only owner can read it as it contains password.
-- 
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
[ <plarkin@iphase.com> PATRICK LARKIN - System Administrator  Interphase Corp. ]
["The opinions expressed herein do not neccesarily reflect those of Interphase"]
[   HOW TO DEFEAT CLIPPER's GOVERNMENT BACKDOOR: Use DES or RSA on top of it!  ]

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 1994 02:25:37 GMT
From:      pdh@netcom.com (P D H)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: are there any generic addresses?

I previously asked:

>Are there any generic addresses?  What I am thinking of here is a set of
>addresses which have been set aside to never appear on the open internet
>but can be used by any organization on its own internal-only networks
>for purposes not needing to go outside.  One advantage of this is that
>this same addresses can be duplicated in each organization.

I got several e-mail replies (Thanks guys!) referring me to RFC 1597 and
one referring me also to RFC 1627.  RFC 1597 gives these available "private
internet" addresses:

class A:    10

class B:    172.16    .. 172.31

class C:    192.168.0 .. 192.168.255


RFC 1627 suggests not using these addresses due to possible problems
one may encounter.  One example is when different organizations or
separate networks are both doing this and have address conflicts and
end up joining, merging or otherwise needing to intercommunicate (even
if not on a "public" basis).  Another example is intraorganizational
communications that need to go by way a "public" provider.  In this
latter case, tunnelling may be a usable solution.

My conclusion is that little links between routers where I really don't
need to access them is a case where problems are not too likely.  Given
that many routers do seem to have problems properly handling a mix of
subnet sizes, I'm pretty much stuck with the subnets we have now and
hate the idea of wasting a whole subnet of 254 addresses just to run
a cable between 2 routers.  Of course if these addresses truly do not
need to be communicated with, I could possibly do all this with just one
subnet for up to 127 of these.

BTW, I've added filtering on my firewall to discard any packet either
from or to any of the above addresses going in either direction.
-- 
    Phil Howard KA9WGN    |    If this is an information superhighway,
    pdh@netcom.com        |    then where is the nearest airport?

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 17:02:52 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: CRC and other Questions

In article <9408050323.AA23866@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
>
> Here are a few random questions that have arisen during a project I am
> working on:
> 
> Does the size of a CRC depend on how much data it is being computed
> from?
> 
    Not any CRC I've ever heard of.  Specifically the ethernet CRC is
    a fixed length field....how on earth would you specify the length
    field for a variable length CRC in something like HDLC where the
    CRC is by definition the last two bytes before the Flag?
> 
> How can a minimum ethernet frame size be specified that is larger than
> the size of the header alone?  Doesn't this prohibit people from sending
> a frame with only one or two bytes of data?

  No.  You just have to have a mutually agreed upon protocol for
  padding out the frame and telling your partner how many bytes of
  data are data and how many are pads.  Using nulls alone wouldn't
  work for obvious reasons....send a frame data from a file which
  includes nulls. 

  A good analogy is a sheet of typing paper.  You don't slice up the
  paper just for a 10 line letter do you?    




-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 08:05:55 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In article <31rutp$6mh@news.iastate.edu> john@iastate.edu (John Hascall)
writes: 
    
        And what exactly would be the incentive for provider A,
        whom you just dumped, to allow you to keep their addresses?
    
Please read the CIDR RFC.  First, the old provider doesn't have a hell of a
lot of choice.  The new provider will gladly (because he's been paid)
advertise the prefix for the site from the old provider's address space.

The old provider can:

- not accept the route, in which case they intentionally cut off service to
their former client -- but they can do this regardless of the address space
used by the former client.

- advertise that prefix too -- again, still can be done with a new address
space as well.

Bottom line: the old provider might as well play nice, because playing
dirty would become extremely nasty, and paybacks are hell.

Tony

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 1994 09:17:11 +0000
From:      Peter@bhcnt.demon.co.uk (Peter Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: Route a subnet with same net number?

In article <PIERCARL.94Aug3165902@sabi.sabi.demon.co.uk>
           piercarl@sabi.demon.co.uk "Piercarlo Grandi" writes:

Thanks for the advice, but I still have a few more questions.

> If you route between your internal net and the external interfaces you
> will have to get one of the corporate subscriptions from Demon, BTW. The
> cheap one is strictly for a single IP address and for a single machine
> on which mail and news are composed and accessed. They have ways to
> monitor exceptions...

This is ok, we are expecting to have to change our connection to a more
permanent link anyway.

> OK, I was just joking. Apparently your internal class B network address
> has not been reserved, so probably somebody else is using it. Then you

How do you know this ?? (Just by pinging the IP numbers ?)

> This means that you need to install daemons on the gateway machine to
> act as application level gateways.

I don't know about this, can you recomend any further reading ?

> For news this is easy; you fetch the news from the internet, and your
> local users just access them on the gateway machine. For mail it is
> almost equally easy; your MTA can act as a mail gateway.

What's an MTA ??

> BTW, in the cas eof news and mail you probably don't want to go thru
> Demon; you really want to use UUCP, which is much more efficient. Dircon
> seems a better choice.

Who are Dircon ?? Where do I get more info on them ?

> For the other services is not as easy. You need specific application
> level proxies, and clients that can use them. For FTP ws_ftp has the
> right client side; I cannot remember which ftpd packages offer proxy
> service. Try having a look around "tns.com". I wish some of the people
> reading this newsgroup could advise on suitable proxy packages.

Is "tns.com" the full node name or just a network ?
What nodes are available here ?

> You also need to be very careful in setting up the DNS on the gateway
> machine; you want to be an incomplete root server for your internal
> network, but not for the internet :-).

Any ideas on how to get around this ?

> There is some enlightening discussion in the "firewall" FAQ, and some
> ideas in the O'Reilly book on TCP/IP.


ATEOTD, Is it going to be easier for me to use a Novell server as our main link
running TCP/IP over a SLIP/PPP line to the PoP, with NetWare on the LAN ???


(ATEOTD = "At The End Of The Day" - Made-up TLA of the day :-)

-- 
Peter Gross                      |Email:      peter@bhcnt.demon.co.uk
UNIX Systems Manager             |*********************************************
Brighton Health Care NHS Trust   |*     #include <usual.disclaimer>           *
UK                               |*********************************************

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 1994 10:47:22 GMT
From:      bjohnson@novell.ur.utk.edu (Bob Johnson)
To:        comp.protocols.tcp-ip
Subject:   test,please ignore

test post , please ignore

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 1994 12:21:05 GMT
From:      josv@inter.NL.net (Jos Vos)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   WANTED: tcpdump utility for AIX

Does the "tcpdump" utility also work on AIX (3.2.5)?

If yes, please mail me where I can find it.

Thanks.

-- 
--   Jos Vos   <josv@NL.net>

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 14:10:51 GMT
From:      khadi@bnr.ca (Kuswara Hadi)
To:        comp.protocols.tcp-ip
Subject:   OSF's DME : what is the story ?

Can somebody following the fate of OSF's DME ? 
I would appreciate some info on this.

Kuswara Hadi 
BNR Ltd
Ottawa, Canada 




-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 1994 14:14:20 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: multicast file transfer?

In article <Cu0wp4.6w4@ecf.toronto.edu> steve@ecf.toronto.edu (Steve Kotsopoulos) writes:

> ...
>There are several RFCs about multicast. The main problem is
>that few vendors provide the OS support. Until this support is
>universally available, it is useful if applications have a
>fall-back mode that does unicast or broadcast if needed. 
> ...

I think now that "most [UNIX] vendors" do support multicasting.
Don't all of Sun, SGI, HP, IBM, and DEC?  At least in their newest releases?


Vernon Schryver    vjs@rhyolite.com

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 14:51:00 GMT
From:      martyn@cs.man.ac.uk (Martyn Spink)
To:        uk.announce,comp.protocols.tcp-ip
Subject:   TCP/IP Protocols Course

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

		TCP/IP Protocols: A Practical Introduction
			   [Code:  TCP/IP-1]

			   Dr. Andy Carpenter

			  15th & 16th September 1994
	
			     Cost : #280.00
                    [discount available for academics]

                                PEVE Unit
                       Department of Computer Science
                         University of Manchester 

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

For Further Details:

Please contact Helen Sheehy via:

Phone:  061-275-6172

Email:  hsheehy@cs.man.ac.uk

Fax:    061-275-6200

Post:   PEVE Unit
	Department of Computer Science 
        University of Manchester
	Oxford Road 
        Manchester M13 9PL

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

Aim:

This course is intended to give a comprehensive introduction to the
TCP/IP protocols that are used on many Local Area and Wide Area
networks, and to impart an understanding of the problems in
establishing, managing, and resolving problems in such networks.

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

Course Outline:

The first day starts by reviewing the Internet and the sort of
services that it has to provide.  Various terms and concepts are
introduced, in particular, the idea of protocol stacks and
addresses.  The rest of the day looks at the telnet and TCP
protocols, and RFCs.

The second day starts by examining other protocols central to the
operation of a TCP/IP network; e.g. UDP, IP and ICMP.  Various
aspects related to the operation of the protocols on particular
physical networks are then considered; for example, the need for ARP
on broadcast networks to discover the network address associated with
a particular IP address.  The course concludes with sections on
routing and advanced services.

The telnet protocol discussion covers the definition of the Network
Virtual Terminal (NVT) and the use of option negotiation to alter the
characteristics of an end-to-end connection.  Various problems of
remote terminal emulation are examined; for example, the perceived
delayed effect of control-C operations due to data buffering within a
network.  This section concludes with a paper exercise to decode a
telnet session, including option negotiation.

The section on the TCP protocol starts by examining the way in which
a reliable byte stream is obtained from a potentially unreliable
network.  Other aspects of the protocol covered are: establishing a
connection, sequence numbers, data transfers, flow control and the
format of the TCP header.  This section contains an exercise to
extract the data from a series of TCP packets and predict the
acknowledgements that are sent.

The IP protocol discussion primarily covers the format of the IP
header, the fragmentation and reassembly of packets that cross
networks, and the use of IP options.  In contrast, the section on UDP
and ICMP protocols concentrates on the uses of these protocols.  As
part of this section there are two paper exercises.  One of these is
on IP packet fragmentation; while the other requires the decoding of
the data passed in a telnet session from a dump of the packets
passing across a physical network.

Routing starts by examining the various IP address classes that are
defined, i.e. A, B and C, and their use.  It then goes on to look at
the routing gateway protocols that are available.  An example of the
operation of a dynamic gateway protocol is used to illustrate this.
The section concludes with a section on subnetting.

The advanced services section covers global naming and network
management.  The naming section covers the need for machine
registration, including the mechanisms involved, and name and domain
name servers.  The network management section introduces the
protocols used, e.g. SNMP and CMOT, and the need for object
identification.  Object identification leads onto network databases;
e.g. MIB.

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

Course Delegates:

The course is suitable for network specialists who intend to become
involved in setting up TCP/IP-based computer networks, in maintaining
and trouble-shooting these networks, or in writing protocol code.

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



--

-----------------------------------------------------------------
Martyn Spink, "Acting" Director, 
PEVE-IT Unit, Department of Computer Science, University of Manchester, 
              Oxford Road, Manchester, M13 9PL, U.K.
Tel: (+44) 61-275 6157         FAX: (+44) 61-275-6200
ARPA: mspink@cs.man.ac.uk   
JANET: mspink@cs.man.ac.uk    UUCP: ..!mcsun!uknet!mucs!mspink
-----------------------------------------------------------------

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 22:04:36 -0400
From:      zaccari@access3.digex.net (Russ Zaccari)
To:        misc.consumers.house,comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.networking
Subject:   Re: advice on tcp-ip cable and telephones sought

I wouldn't think that you would have a problem w/ level 5 utp but I would 
make two runs of 4-pair level 5.  Just consider the possibility of 
wanting two nodes in one location or multiple phones.  Its easier to run 
it once and do it right.

Russ...
zaccari@digex.net

In article <31ot0h$e6i@steele.ohsu.edu>, Milton Hill <hillm@ohsu.edu> wrote:
>Hi - A quick question about wiring my new house:
>If I go with a catagory 5 10BaseT/UTP cable to make
>a small tcp/ip network can I do the following - 
>The cable is 4 pair, I would like to run phone
>signal over 1 pair and network over the others.
>Does anyone think there would be a problem with
>inter ference?
>
>Thanks
>Milt
>hillm@ohsu.edu



-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 1994 16:48:30 +0000
From:      outmail@bhcnt.demon.co.uk (Peter Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: PCs as IP routers

In article:  <775490596snz@peeras.demon.co.uk>
  proyse@peeras.demon.co.uk (Phil Royse) writes:
> 
> In article <775495382snx@cdc.demon.co.uk>
>            pdb@pdb.compd.com "Peter Burnett" writes:
> 
> >>KA9Q is also probably worth looking into.
> >
> >Indeed.... I use it here as a mail-relay, local inhouse nameserver and
> >as a local in-house router. Version I am using is the Demon Internet
> >Service supported version ( 2.15 ).
> >
> >Regards,
> >Peter.
> 
> Peter,  I use KA9Q for Demon access, but I did't know it could route.
> Does that mean you can configure it to see an NE2000 Ethernet card 
> in the same PC IN ADDITION to seeing the COM1 port?  
> (I use WfWG 3.11 between my two PCs (over NE2000s).)
> 
> Could you post the appropriate config info?  That is, to get KA9Q looking
> at an Ethernet card?  Is it all in the AUTOEXEC.NET file?  or do you need
> packet drivers and PROTOCOL.INI statements and binds and things?
> 

Does this mean that you could have a Novell server running SLIP/PPP on a
COM port to Internet, and NetWare on the Ethernet card ?

(Assuming I have relevant agreement with Internet provider - Demon :-)

How does this work for FTP ?

ie. Does user have to FTP from Net to Server to PC
    or
    FTP (via proxy FTP on server) direct to local PC ???

What about getting News and Email ?

Is there a FAQ regarding this (if not there should be :-) ??

                                ******

Peter Gross                      |Email:      peter@bhcnt.demon.co.uk
UNIX Systems Manager             |*********************************************
Brighton Health Care NHS Trust   |*     #include <usual.disclaimer>           *
UK                               |*********************************************


-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 94 19:58:30 GMT
From:      n8641322@animal.cc.wwu.edu (Richard D. Huff)
To:        comp.protocols.tcp-ip
Subject:   HELP: traceroute to my site?

Would anybody be willing to help me trace down where my IP traffic is dying
on the net?  I need a couple people to do a traceroute from their site to IP
address 204.93.1.2 and relay the information back to me.  The traffic seems
to be lost somewhere between the NSFnet and SprintLink.  I have a CIX
connection also; so, if I can get traceroutes from a couple different sites
on the net I may be able to work with the responsible party to solve my
problem.

TIA, 

Richard D. Huff
Pacific Rim Network, Inc.
tel (206) 650-0442
fax (206) 738-8315
e-mail: n8641322@henson.cc.wwu.edu
(e-mail is temporary until I can identify the problem)

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 1994 22:01:24 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast delivery

In article <31jkhl$bft@goshen.connected.com> warrl@connected.com (Donald Edwards) writes:
>matt b (mbolce01@kadavu.ae.eds.com) wrote:
>
>: Could anyone provide me some insight as to the proper socket code
>: semantics to use to issue a packet with a destination address of
>: "255.255.255.255"?  I have already tried setting the socket option
>: for SOL_BROADCAST to true, with no luck.  I seem to only be able to
>: broadcast to all hosts on a known network (e.g., x.x.x.255), but get
>: routing problems with the "255.255.255.255" dest, or a "bad value"
>: when I try to force a route out an interface for that broadcast
>: destination.  I have a feeling I'm missing something obvious.
>
>One obvious thing is that not every IP address in the world needs to
>receive the packet...   

What does that have to do with this?  The definition of 255.255.255.255 is
(according to RFC 1122, section 3.2.1.3) that the datagram "will be
received by every host on the CONNECTED PHYSICAL NETWORK" (emphasis mine).
There is no address that designates "every IP address in the world."

The problem the original poster is encountering is that Unix (or some
versions, at least) only recognizes broadcast addresses that match the
broadcast address for an interface.  So, to send a broadcast through an
interface you have to use an ioctl to get its broadcast address.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 94 22:33:34 GMT
From:      hal9001@panix.com (Robert A. Rosenberg)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In Article <naran.776018355@sfu.ca>, naran@fraser.sfu.ca (Travers Naran) wrote:
>weave@hopi.dtcc.edu (Ken Weaverling) writes:
>
>>Imagine a likely scenario. I am commercial company planning on putting up
>>a Web server, gopher, etc, to offer sales lit, support, etc, to my
>>customers and potential clients.  I find out that a lot of sites can't
>>reach it because they are behind providers that don't shell out the $10K
>>to CIX. I'd be friggin pissed and take my net business elsewhere. 
>
>So you would set-up a somewhat permenant connection to the Internet via
>CompuServe?  Why!?  There are many lower cost providers in North America.  In
>fact, several companies (and even a few research networks) are offering
>low-cost Internetn connections for corporation and other businesses.
>

There is one point that you are missing - the $10k fee is not to allow
access to CIX reachable networks (or access from these networks) but to
allow traffic traveling  between two non-CIX networks to use the CIX network
for some of their hops. Thus if Mr. Weaverling sets up his WWW server with a
provider who has not paid the fee and you wanted to access it (assume your
provider is not a CIX site), your request would still go though but would
not be allowed to traverse the CIX network (even if use of the network would
shorten the route). If both providers were CIX (or had paid the fee) then
the routing could use the CIX network. Calling the WWW server from a CIX (or
fee-paid) provider allows the CIX network to be used since one end has CIX
authority (if the CIX side is dual-hosted and can route bypassing the CIX
network the CIX routes may or may not be usable [I'm not sure of the
rules]).

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Aug 1994 22:59:35 GMT
From:      macedoni@cs.nps.navy.mil (mike macedonia)
To:        comp.protocols.tcp-ip
Subject:   Re: multicast file transfer?

Vernon Schryver (vjs@calcite.rhyolite.com) wrote:
: In article <Cu0wp4.6w4@ecf.toronto.edu> steve@ecf.toronto.edu (Steve Kotsopoulos) writes:
 
: > ...
: >There are several RFCs about multicast. The main problem is
: >that few vendors provide the OS support. Until this support is
: >universally available, it is useful if applications have a
: >fall-back mode that does unicast or broadcast if needed. 
: > ...
 
: I think now that "most [UNIX] vendors" do support multicasting.
: Don't all of Sun, SGI, HP, IBM, and DEC?  At least in their newest releases?


Sun, SGI, and DEC do actively support ip multicast in their latest OS. HP and IBM can provide ip multicast but I do not think they are actively supporting it. (You can get it.) 

I beleive Chicago and Windows NT with soon have mcast support.

The problem with multicast is *scalable* reliability which means it is not appropriate yet for applications that need guaranteed delivery to lot of host. 

Broadcast is useless for wide area nets and unicast does not scale.  


--
Mike Macedonia | macedonia@cs.nps.navy.mil
MAJ, USA       | CS Dept, Naval Postgraduate School,
               | Monterey, CA 93943
               | PH:(408) 656-2903  FAX:(408) 656-2814
------------------------------------------------------------

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Aug 1994 00:16:28 GMT
From:      dan@dpcsys.com (Dan Busarow)
To:        comp.protocols.tcp-ip
Subject:   Re: A good idea for internet developer's !

JParadis (jparadis@courrier.usherb.ca) wrote:
> I would like to see a client server product that could give the
> geographical
> location of an I.P. addresse. And it would be great to find it for
> Macintosh,

whois works just fine if you have it.  Just give it the network portion 
of the address, 132.210 in your example, and you can get back the 
street address etc.. for the organization it is registered to.  

% whois 132.210
Universite de Sherbrooke (NET-USHERB-NET)
   2500 Boulevard Universite
   Sherbrooke, Quebec, J1K 2R1
   CANADA

That's as close as you are going to get since the NIC doesn't have 
address data on individual hosts and IP addresses have nothing to do 
with geography.

Dan
-- 
   Dan Busarow               dan@dpcsys.com                 uunet!cedb!dan
   DPC SYSTEMS                Monrovia, CA                  (818) 305-5733

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 1994 22:51:12 -0700
From:      guy@nova.netapp.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI & WANs

>TLI is not really the appropriate interface to these things.  AT&T have
>two other standards, DLPI and NPI which (half-)define interfaces to the
>Data Link and Network layers; NPI is the closest of these to get to X.25;
>I'm not sure if DLPI or NPI would be appropriate for Frame Relay or ATM.

If the intent is to run IP over X.25, Frame Relay, ATM, etc., presumably
DLPI, not NPI, would be appropriate....

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Aug 1994 11:35:33 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: PCs as IP routers

In article <454295129wnr@bhcnt.demon.co.uk>
           outmail@bhcnt.demon.co.uk "Peter Gross" writes:

>
>Does this mean that you could have a Novell server running SLIP/PPP on a
>COM port to Internet, and NetWare on the Ethernet card ?
>
>(Assuming I have relevant agreement with Internet provider - Demon :-)
>
>How does this work for FTP ?
>
>ie. Does user have to FTP from Net to Server to PC
>    or
>    FTP (via proxy FTP on server) direct to local PC ???
>
>What about getting News and Email ?

Peter,

My understanding of using a PC as a router is just that, a router.
That is, it doesn't simultaneously act as a client or server.  The 
way it would work for KA9Q (or equivalent) would be that the PC router
is connected to the Internet via its SLIP or PPP connection (COM1) and
to its local Ethernet via a standard network card.  The protocols
on both interfaces would be IP.  Each other host PC on the Ethernet
would need its own IP address and name, and would act as a client
or host for Internet (Demon) services.  That is, one PC user could
FTP to one distant host and and another local PC user could telnet
somehwre else.  These sessions could/should operate independently.

In this context the PC router is entirely passive (in forwarding
IP packets).  I.e there is is no need for it to be a proxy or for
it to translate any packets etc.

On the other hand, what you have suggested is available from
Novell (or Firefox).  They do a Novell server application which lets
N novell clients (on a small local Ethernet) share up to M IP addresses
by some sort of proxy function in the Novell server.

I am looking into setting up the former type of connection to the 
Internet for some clients.  I think the use of a PC as a passive 
router is the easiest/cheapest way.

>Is there a FAQ regarding this (if not there should be :-) ??

Yes, there should be, but I don't know of one.

>Peter Gross                      |Email:      peter@bhcnt.demon.co.uk
>UNIX Systems Manager             |*********************************************
>Brighton Health Care NHS Trust   |*     #include <usual.disclaimer>           *
>UK                               |*********************************************
 
-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Aug 1994 12:35:08 +0000
From:      nick@tweed.demon.co.uk (Nick Felisiak)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI & WANs

In article <31mci1$tp@progress.progress.com> chandler@chatham.progress.com (Peter Chandler) writes:
>I am looking for TLI drivers for Wide Area Network (WAN) protocols.
>The WAN protocols are X.25, frame relay, SMDS, ATM, etc.  A TLI-WAN
>driver should be supported on multiple hardware platforms.  Does
>anyone know of a vender/product which allows TLI support with an
>under laying WAN protocol? 
>

TLI is not really the appropriate interface to these things.  AT&T have
two other standards, DLPI and NPI which (half-)define interfaces to the
Data Link and Network layers; NPI is the closest of these to get to X.25;
I'm not sure if DLPI or NPI would be appropriate for Frame Relay or ATM.

Having said that, Sun have put a socket interface over X.25; I'm not
sure how they deal with things like Reset and Restart messages, D-bit
notification, etc.

Nick
-- 
Nick Felisiak						nick@tweed.demon.co.uk
Copestone Research Ltd					+44 721 730 288
Eddleston by Peebles, Scotland
	   Networking, Unix, and Embedded Systems Consulting

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 1994 03:09:50 -0700
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP: traceroute to my site?

In article <n8641322.776116710@animal>, n8641322@animal.cc.wwu.edu
 (Richard D. Huff) wrote:
>Would anybody be willing to help me trace down where my IP traffic is dying
>on the net?

I did some traceroute's and found that you are reachable from the
CIX side but not from the NSF side.  In the latter case the ENSS
router at the boundary of the NSFnet/ANSnet backbone rejected the
packet with a "host unreachable" when it attempts to enter the
NSFnet/ANSnet backbone.  This means that the NSFnet/ANSnet doesn't
know about your network (i.e. has no route to it).

Did your network (204.93.1) agree to the NSFnet Backbone Network
Service AUP and thus obtained "NSF routing"?  If not, that would
explain why the NSFnet/ANSnet backbone doesn't know how to get to
you.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"Packet Driver, WinSock & TCP/IP CD-ROM" product information:
{gopher,www,ftp}.CDPublishing.com or <info@CDPublishing.com>


-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 94 23:06:00
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: A good idea for internet developer's !

We've had semi-joking customers mention that SNMP-readable GPS receivers
in our routers would be a nice thing...

BillW

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      06 Aug 1994 18:44:25 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: multicast file transfer?

> I think now that "most [UNIX] vendors" do support multicasting.
> Don't all of Sun, SGI, HP, IBM, and DEC?  At least in their newest releases?

Not HP. There are patches available for HP-UX 9.01 which will make an
HP box do IP multicasting, but it's not supported. No patches available
for 9.03 or 9.05.

As far as I know it *will* be standard in HP-UX 10.0.

Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      6 Aug 1994 22:26:28 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: multicast file transfer?

In article <Cu2FJw.31C@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:

>I think now that "most [UNIX] vendors" do support multicasting.
>Don't all of Sun, SGI, HP, IBM, and DEC?  At least in their newest releases?

No, and the facts say a great deal about the quality of software and
interest in meeting customer needs from certain vendors (namely HP and
IBM).

IBM has no released or announced (or, as far as I can tell, bootleg)
support for IP multicast in any version of AIX.

HP let some unofficial multicast kernel patches for HPUX 9.x circulate
for a brief period, but HP has since "withdrawn" the patches because
they think their customers are too stupid to install a kernel patch.
No officially released HP system supports IP multicast.  There were
false rumours that it would appear in HPUX 9.x and there are current
rumours that it will appear in HPUX 10.x (whenever that gets
released).  Usually reliable sources indicate that HP's Cupertino
operation, which includes most of their networking folks, is being
"downsized" these days.  Implications for future product features
can't be good if those rumours are true (mind, HP has usually been in
last place on networking capabilities for a while now).

SGI, Sun, and DEC have supported IP multicast for a while now.
Unofficial multicast patches for SunOS 4.1.x and Ultrix are available
on the net.  SGI has supported multicast for a long time so its users
don't need to do anything special.

Ran
atkinson@itd.nrl.navy.mil

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 1994 01:22:02 GMT
From:      manolo@rcf.rsmas.miami.edu (Manolo Hernandez)
To:        comp.protocols.tcp-ip
Subject:   standard

 Were can I get some public domain libs for TCP/IP and related products? I 
need this for either OS/2 or MS-DOS. PD would be great but if thier is no 
other way I guess I will have to pay for it.


Please E-Mail me with any info. Thanks.



   MANOLO HERNANDEZ


The one and only computer language is the one you know.
OS/2 Guru, Windows hater, and UNIX enthusiast. C and Pascal programmer 
extrordinare. Waiting to kill Visual Basic. Go VISUAL PASCAL.


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 1994 06:36:10 GMT
From:      sanner@noc.usfca.edu (David J. Sanner)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Mult. Class C on one physical network?


Hi,

I am going to be setting up a Cisco router with multiple ethernet
segments.  I am wondering if I can have multiple Class C network
numbers on the same segment/physical-network ?

If I can do this:
- What problems might I encounter with two or more hosts on the same physical
  network having different class c broadcast addresses?
- Will the router try to answer arp requests for hosts trying to send
  to another host on the same physical net but in a diff. class C network?

I have heard of sites putting two subnets on the same physical network.
The problems I have heard with that is that is that the router can  
can answer a ARP request for a host so that any IP packets traveling
from host A to host B (Hosts A and B are in different subnets
but share the same physical network) travels from host A to the
router and then back to host B thus doubling the network traffic.

If I can't do this:
- What the heck do folks do when can only get class C addresses and
  want to have more that 254 hosts on a physical net?
- Any other ideas?

	Thanks for your time and help,

				David.

--
----------------------------------------------------------------------------
David J. Sanner - Physics Research Dept. at the University of San Francisco
I have great faith in fools -- self confidence my friends call it.  - E.A. Poe
 -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_--_-

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Aug 1994 13:21:32 GMT
From:      dirk@incom.de (Dirk Koeppen)
To:        comp.protocols.tcp-ip
Subject:   Re: multicast file transfer?

We have worked out an extension to TFTP for multicast based file transfers.
This has already been implemented and we are testing with about 50 
concurrent loading systems in our project. In order to RFC these add-ons
we need to finish the project and then write the RFC.

If someone else is working on that topic please get in contact with me. We
use the MTFTP protocol to diskless boot clients concurrently from one server
using multicast TFTP frames. Clients can also fall back to unicast.

Thanks,
dirk


--
                   Dirk Koeppen EDV-Beratungs-GmbH
            Holzwiesenweg 22 * D-63073 Offenbach * Germany
  Phone: +49 69 89 3000 * FAX: +49 69 89 3004 * email: dirk@incom.de

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Aug 1994 13:34:15 GMT
From:      sysman1@un.seqeb.gov.au (The Fantom Ferret)
To:        comp.protocols.tcp-ip
Subject:   Code for RFC1219 ?

Before I reinvent the wheel - has anyone implemented RFC1219 (On the
Assignment of Subnet Numbers) as a software package ? 

--
Graeme Wightman (GW211) - System Support  Email: ferret@alfalfa.seqeb.gov.au
South East Queensland Electricity Board	  Fax:   +61 7 2217556
GPO Box 1461, Brisbane 4001 AUSTRALIA	  Phone: +61 7 2234150

             <<< GOD is REAL .... unless declared INTEGER >>>

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Aug 94 19:48:53 +1200
From:      David_Liebert@equinox.gen.nz ( )
To:        comp.protocols.tcp-ip
Subject:   bootp and resolver lib question

If bootp is set up to assign IP addresses, do the hostnames in /etc/bootptab
link into the resolver library somehow?  I would like to set up a small
Linux box to act as a bootp server to 120 PCs running pctcp and would
probably
make this a name server as well, but I don't want to have to have the
problem of keeping /etc/bootptab and /etc/hosts in sync.

If replying by mail, please post to liebertd@ecnz.co.nz

With thanks.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 1994 15:50:20 GMT
From:      sab@phantom.com (Zippy)
To:        comp.protocols.tcp-ip
Subject:   Two class C nets on one phys link

Is it possible to have two different class C networks (subnet 255.255.255.0)
sharing the same physical link (i.e., same coax segment, or, in our case,
the PBX)?  The two networks will be isolated, so routing is not (yet) an
issue.  

Related questions:  What happens to the ARP tables of a machine when it 
discovers traffic from another network on its network?  (will it even 
make it to the ARP table?)  Will routing protocols be affected?  Which ones? 

Please reply via e-mail to sab@phantom.com.  If there is interest, I'll
summarize.

Thanks.
--
Seth Bromberger
sab@phantom.com

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 94 00:34:02
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   unix telnetd's modified to do local echoing when possible?

Well, now that rfc1184 has been out of a "long time", has anyone produced
a modified telnetd for "generic unix" that uses line mode whenever possible?

How about a compromise, and just a telnetd that uses local echoing whenever
possible?

The specific unix of interest at the moment is AIX, if it matters.

Thanks
BillW.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Aug 1994 19:44:08 GMT
From:      brettf@netcom.com (Brett Frankenberger)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Mult. Class C on one physical network?

sanner@noc.usfca.edu (David J. Sanner) writes:

>I am going to be setting up a Cisco router with multiple ethernet
>segments.  I am wondering if I can have multiple Class C network
>numbers on the same segment/physical-network ?
>
>If I can do this:
>- What problems might I encounter with two or more hosts on the same physical
>  network having different class c broadcast addresses?

Should work OK ... the typical way this works is that traffic goes in
and out your router ... but you may be able to handle that by
configuring static routes on your hosts.  (For host A on subnet A,
configure a static route to subnet B with the adresses of Host A as the
next hop ... this won't always work ... if not, you'll have to let the
packets go in and out of the router ...)

>- Will the router try to answer arp requests for hosts trying to send
>  to another host on the same physical net but in a diff. class C network?

Not unless proxy ARP is enabled on the router.  But that's not what
causes the packets to go in-and-out of the router ... the workstation
(host) realizes that it is sending to another subnet and wants to use a
router ... so it consults its routing tables.

>I have heard of sites putting two subnets on the same physical network.
>The problems I have heard with that is that is that the router can  
>can answer a ARP request for a host so that any IP packets traveling
>from host A to host B (Hosts A and B are in different subnets
>but share the same physical network) travels from host A to the
>router and then back to host B thus doubling the network traffic.

Unless you can get the static routes I mentioned above to work, you
will double the traffic ... but not because of ARP, but because IP
hosts usually want to use a router to talk to a different network.

>If I can't do this:
>- What the heck do folks do when can only get class C addresses and
>  want to have more that 254 hosts on a physical net?

Usually they put multiple nets on one cable ... on our network, we
split it into two networks with a router in between long before 254
hosts, though.
-- 

          - Brett  (brettf@netcom.com)
 
------------------------------------------------------------------------------
                               ... Coming soon to a      | Brett Frankenberger
.sig near you ... a Humorous Quote ...                   | brettf@netcom.com
 

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Mon, 08 Aug 1994 11:38:14 -0800
From:      hayes@rassp.hac.com (Brian S. Hayes)
To:        comp.protocols.tcp-ip
Subject:   File Transfer between Macs and Suns

I'm writting an application that will need to perform file transfers from 
the Sun to a Mac.  Is there any source code out there that deals with this?
I would appreciate any pointers on this subject.

end -- Brian                                                  \\:^)
Brian S. Hayes             | Internet : hayes@rassp.hac.com
Hughes Aircraft Company    | MicroSoft: bhayes@msmail4.hac.com
MS: RE/R01/A528            | Voice    : (310) 334-8433
PO Box 92426               | RASSP Hot Line: (310) 334-5404
Los Angeles, CA 90009-2426 | RASSP Fax     : (310) 334-1672

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 08:01:05 -0500
From:      lin@cs.purdue.edu (John Chueng-Hsien Lin)
To:        comp.protocols.tcp-ip
Subject:   Re: multicast file transfer?

In article <Cu62Fx.FnG@dksoft.incom.de>, dirk@incom.de (Dirk Koeppen) writes:
> We have worked out an extension to TFTP for multicast based file transfers.
> This has already been implemented and we are testing with about 50 
> concurrent loading systems in our project. In order to RFC these add-ons
> we need to finish the project and then write the RFC.
> 
> If someone else is working on that topic please get in contact with me. We
> use the MTFTP protocol to diskless boot clients concurrently from one server
> using multicast TFTP frames. Clients can also fall back to unicast.

I have a question. Can your MTFTP protocol handle Internet muticast
file transfer? Internet multicast file transfer is more interesting than
LAN multicast file transfer, IMHO.

John Lin (lin@cs.purdue.edu)





-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 13:33:08 -0700
From:      markb@spock.dis.cccd.edu (Mark Bixby)
To:        comp.protocols.tcp-ip
Subject:   Re: pacbell isdn

In article <bearbj.195.2E465B4E@crash.cts.com>,
Brian S. Jones <bearbj@crash.cts.com> wrote:
>Anyone have any experience connecting to the internet using ISDN from Pac Bell?

I don't have the first-hand experience, but PacBell does have a web page on 
the subject:

	http://www.pacbell.com/isdn/isdn_home.html
-- 
Mark Bixby                         Internet: markb@cccd.edu
Coast Community College District   1370 Adams Avenue
District Information Services      Costa Mesa, CA, USA  92626
Technical Support                  (714) 432-5064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 03:26:04 GMT
From:      lapp@waterloo.hp.com (David Lapp)
To:        comp.protocols.tcp-ip
Subject:   Re: A good idea for internet developer's !

JParadis (jparadis@courrier.usherb.ca) wrote:
: I would like to see a client server product that could give the
: geographical
: location of an I.P. addresse. And it would be great to find it for
: Macintosh,
: since i have fall down the apple basket for 10 years now...
: If it already exist let me know...
: Enter 132.210.XXX.XXX on your client, server reply
: Sherbrooke,Quebec,Canada
: Canada is only for a indeterminated time ... Countdown is already
: started ...

And reconfiguring the database(s) to remove "Canada" the day after the
referendum may be the least of your problems...

: If you want to put time on it and make money whit it... Don't forget
: your idea's lighter...jparadis@courrier.usherb.ca  
: I'm to buzy for this kind of work now... 

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 11:49:29 -0500
From:      cscott@Starbase.NeoSoft.COM (Clint Scott)
To:        comp.protocols.tcp-ip
Subject:   Salary Compensation?

I am interested in a compensation survey of people with UNIX and TCP/IP 
skills.  These skills include sys admin, app development, net admin, etc.
Any information will be appreciated.  I'm doing this work on my own.
If anyone can point me to another location (this side of hell...thank you)
please let me know.
cscott@sugar.neosoft.com

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 13:32:37 -0600
From:      dbform@tibalt.supernet.ab.ca (Data Business Forms)
To:        comp.protocols.tcp-ip
Subject:   ftp

Is there any way to automate FTP?  What I want to do is the following:

	Have a user type a command -- eg: transfer   -- and have ftp open a 
session with a unix host and transfer the files to the host, and then 
close the session and quit ftp.

	All without the user knowing what is going on.  A batch file really.

Any and all responses will be greatly appreciated.

THX

David Wood


-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 15:29:13 -0700
From:      stevel@crl.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Multiple host mail - how?

I am writing an SMTP gateway for my companies TCP/IP package and am unclear
on something.  How is configuration usually handled which allows users
to specify a domain (say foobar.com) and have the mail properly arrive
at different hosts? (say, john@foobar.com and jane@foobar.com end up
going to john@sales.foobar.com and jane@support.foobar.com)

Is this somehow done with the DNS records, or am I missing a configuration
file?  Everything else works to this point, but I am unclear how other
sites are handling the above situation.

Much thanks in advance.

- stevel@crl.com


-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 07:40:25 GMT
From:      jmack@skye.phys.ualberta.ca
To:        comp.protocols.tcp-ip
Subject:   Re: A good idea for internet developer's !

In article <3248kc$q20@hppadbk.waterloo.hp.com> lapp@waterloo.hp.com (David  
Lapp) writes:
> JParadis (jparadis@courrier.usherb.ca) wrote:
> : I would like to see a client server product that could give the
> : geographical
> : location of an I.P. addresse. And it would be great to find it for
> : Macintosh,
> : since i have fall down the apple basket for 10 years now...
> : If it already exist let me know...

There is an ongoing gopher client project which generates a gopherspace "map"
based on some primary geographic data (location data is supported in the newer
gopherd's as a config record), but I can't for the life of me remember the name
of the app. It runs in a NeXT environment, available for PC's, HP, native NeXT
hardware, and soon on SUNs...

--
James S. MacKinnon             Office: P-139 Avahd-Bhatia Physics Lab
Computing/Networking           Phone : (403) 492-8226
Department of Physics          email : jmack@phys.ualberta.ca
University of Alberta          uucp  : uofaphys!jmack  iskye!jmack
Edmonton, Canada T6G 2N5       bitnet: jmack@triumfcl  jsm1@ualtamts

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 94 14:10:49 +1100
From:      dgingram@actew.oz.au (Dougal Ingram)
To:        comp.protocols.tcp-ip
Subject:   Looking for IP address management software

My organisation will shortly be installing TCP/IP software on approximately 600 
PC's.

IP addresses will be allocated according to a schema based upon geographical
location and will be hard coded to each PC.

I am looking for some software to manage a database of these addresses and 
hopefully to allocate new addresses.  If necessary I will write something in
Visual Basic/Access but am hoping to avoid this due to time constraints.

Any suggestions or pointers would be gratefully appreciated.

TIA 
-- 
------------------------------------------------------------------------------
Dougal Ingram            ||   Email: dgingram@actew.oz.au                     
PC Product Support,      ||   Snail: GPO Box 366, Canberra ACT 2601, Australia 
ACT Electricity & Water  ||   Voice: +61-6-248-3495 (w)  Fax: +61-6-248-3439   
------------------------------------------------------------------------------  

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 16:37:51 -0400
From:      varora@cs.umd.edu (Vivek Arora)
To:        comp.protocols.tcp-ip
Subject:   Bit Ordering


Here is a piece of code defining the ip header taken  from NetBSD TCP/IP 
implementation.

struct ip {
#if BYTE_ORDER == LITTLE_ENDIAN
        u_char  ip_hl:4,                /* header length */
                ip_v:4;                 /* version */
#endif
#if BYTE_ORDER == BIG_ENDIAN
        u_char  ip_v:4,                 /* version */
                ip_hl:4;                /* header length */
#endif
        u_char  ip_tos;                 /* type of service */
        short   ip_len;                 /* total length */
        u_short ip_id;                  /* identification */
        short   ip_off;                 /* fragment offset field */
#define IP_DF 0x4000                    /* dont fragment flag */
#define IP_MF 0x2000                    /* more fragments flag */
        u_char  ip_ttl;                 /* time to live */
        u_char  ip_p;                   /* protocol */
        u_short ip_sum;                 /* checksum */
        struct  in_addr ip_src,ip_dst;  /* source and dest address */
};

My question is that does the order of bits in a byte also depend upon
the  "Endianess" of the machine ? If yes why isn't any bit order 
conversion required for other fields? 


Here is the relevant portion of the IP header format taken from RFC 791.
 
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


-Vivek
varora@cs.umd.edU


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 11:12:03 +0000
From:      nick@tweed.demon.co.uk (Nick Felisiak)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI & WANs

In article <321sog$eko@nova.netapp.com> guy@nova.netapp.com (Guy Harris) writes:
>>TLI is not really the appropriate interface to these things.  AT&T have
>>two other standards, DLPI and NPI which (half-)define interfaces to the
>>Data Link and Network layers; NPI is the closest of these to get to X.25;
>>I'm not sure if DLPI or NPI would be appropriate for Frame Relay or ATM.
>
>If the intent is to run IP over X.25, Frame Relay, ATM, etc., presumably
>DLPI, not NPI, would be appropriate....

Yes; however, to support this functionality, an extra layer is needed
to provide call management, etc.  This would have DLPI at the top,and
NPI or DLPI at the bottom.

As an aside, DLPI and TPI seem to have been widely adopted; I haven't
heard a lot about NPI.

Nick


-- 
Nick Felisiak						nick@tweed.demon.co.uk
Copestone Research Ltd					+44 721 730 288
Eddleston by Peebles, Scotland
	   Networking, Unix, and Embedded Systems Consulting

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 11:15:23 +0000
From:      ash@cellar.demon.co.uk (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   LCS-8634 Network cards; any info?

I have "inherited" half a dozen rather smart looking network cards.
They are marked LCS-8634 and certainly *look* like Ethernet cards.
Does anyone know anything about these, the switch settings and
which packet driver to try?
I tried the NE2000 driver at the usual settings (IRQ3, I/O 300h)
and it locked up. The cards appear to have DMA jumpers; don't
rememeber seeing an NE2000 with those.
I expect they'll turn out to be Arcnet or something :-(
Any info gratefully received.
Thanks.
A.
-- 
+---------------------------------------------------------------------+
| Andrew Hardie                            Telephone: +44 71 219 5996 |
| London, England                                Fax: +44 71 219 5997 |
+---------------------------------------------------------------------+

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 94 11:34:55 GMT
From:      sheela@eden.rutgers.edu (Isis Leslie)
To:        comp.protocols.tcp-ip
Subject:   Re: are there any generic addresses?

nelson@crynwr.crynwr.com (Russell Nelson) writes:

>In article <pdhCty3B4.BDv@netcom.com> pdh@netcom.com (P D H) writes:
 
>   Are there any generic addresses?  What I am thinking of here is a set of
>   addresses which have been set aside to never appear on the open internet
>   but can be used by any organization on its own internal-only networks
>   for purposes not needing to go outside.  One advantage of this is that
>   this same addresses can be duplicated in each organization.
 
>   Of course I could just "steal" any address.  But I would want to make
>   these "stolen" addresses are not routed out to the open network and
>   there may well be machines in a "common area" that wish to communicate
>   with both the open internet as well as the isolated network.
 
>   The purpose of "stealing" addresses would be to get more addresses
>   without having to acquire more of the address space needlessly since
>   much of the network would be isolated.  It just seems to me that if
>   some addresses were set aside for this it would be easier to deal with.
 
>There's an informational RFC to do this.  Bunches and bunches of
>people had an [a]rousing discussion of this at the last Interop.  At

...very familiar anecdote deleted (but go back and read it if you missed
it)  one of those "have this ever happened to you before?" 's

Anyway for subnets NOT connected to the Internet, these blocks of address
space have been set aside (rfc 1507)

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 -192.168.255.255

Anyway I recommend that even if you only connect one host or nothing at all,
that you use these numbers.  After all, it'll save work if you only connect
one host or one subnet in the future and if you go and get a full network
number, you'd have to change all your addresses anyway....
 
My predecessor (and now co net admin, but we worked for two different bu
privately linked companies) used the sun default address for everything...
He already has network addresses which duplicate ones already on the
net.  Luckily I can stop the boradcasts at my nethost...you may not be so
lucky...
 
peace-Isis

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 18:17:28
From:      karl@cavebear.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: pacbell isdn


>Anyone have any experience connecting to the internet using ISDN from Pac Bell?

Yup.  I've got one into my house for net access.

I've got the Combinet 160 bridge and I keep the B channels up 24 hours a day 
if I can.

It works quite well.  (But I wish I had a T-1.)

The cost is pretty reasonable because I'm on a Centrex arrangement.  
Otherwise the penny a minute + 4 cents to bring up a connection would get 
tiresome.

Pactel seemed to be somewhat beyond their capabilities when getting it 
installed.  It took forever (over a month), they had to dig up about 1/4 mile 
of my street, bring a half dozen new pair of wire into my house, and sent about
three different crews out at different times.

On the other hand, I've used Pactel ISDN over in San Jose (I'm in Santa Cruz) 
and it went in in a couple of days without a hitch.

The reliability has been pretty good so far.

                      --karl--


-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 21:55:56 -0400
From:      altman@usceast.cs.scarolina.edu (Mitch Altman)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp

dbform@tibalt.supernet.ab.ca (Data Business Forms) writes:

>Is there any way to automate FTP?  What I want to do is the following:
 
>	Have a user type a command -- eg: transfer   -- and have ftp open a 
>session with a unix host and transfer the files to the host, and then 
>close the session and quit ftp.
 
>	All without the user knowing what is going on.  A batch file really.
 
>Any and all responses will be greatly appreciated.
 
>THX
 
>David Wood


The easiest way to do this is to create a text file with all of the ftp
commands including the username and password. and then do something like
this

ftp ftp.some.where < textfile

ftp will read the text file just as it would read user input from the
keyboard. This will work most of the time, unless the author of the ftp
program went out of his way to prevent it.

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 15:19:13 GMT
From:      dlgover@ne3.newera.ab.ca (Donald L. Gover)
To:        comp.os.ms-windows.networking.tcp-ip,comp.unix.bsd,comp.protocols.tcp-ip,comp.os.386bsd.questions
Subject:   SLIP->BSDI V1.1->Digiport->Winsock Problem

I've been working on getting a slip line brought using winsock and a BSDI
V1.1 system connected with a Digiport. While I have made many slip connections
work with a telebit netblazer I'm compleatly unable to get this puppy to
work. 

  The Winsock system connects to the BSDI system and completes the login. 
slip.host and slip.login are looked at and run and the SL0 interface is 
started as seen in ifconfig and netstat -i. Also the routing information 
seems to be ok as show by netstat -rn. But when you try to ping the
winsock system there are no replys. On the winsock system if you trace ip
packets. There is a message about ICMP checksum errors with each inbound
packet from the BSDI system. 

  Dose anyone have any ideas? Also is there anyproblem running slip througth
the digiport box? I thought that maybe the digiport box might not like to run
binary data so I set up a uucp link and that worked with out error. 

  Thanks don...



--
=========================================================================
Donald L. Gover                             New Era Systems Services ltd
Internet                                    #710, 425 1st Str. S.W.
office: dlgover@newera.ab.ca                Calgary, Alberta
home:   dlgover@dlgsys.cuc.ab.ca            Canada T2P 3L8
Phone:  (403) 231-9181
=========================================================================

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 15:23:31 GMT
From:      dave@gate.net (David Moses)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for Windows 3.11


I am currently looking into windows programs that can telnet to other
unix terminals in the office over a Novell 3.12 network.  I am using
Core Winsock, but for some reason cannot ping to another terminal.
I am using a packet driver for the Intel Etherexpress 16 network card.

What I am asking is if anyone is using windows software to ping and telnet
to other machines over a novell 3.12 network, and if so, what are they
and how can I get a hold of them, or a demo of them.

Any information is greatly appreciated.

-Dave  

e

--

+--------------------+--------------------------------------------------+
|     Dave Moses     |            Internet: dave@gate.net               |
+--------------------+          CompuServe: 74127,677                   |
                     |             Prodigy: DWBC85A                     |
                     +--------------------------------------------------+



-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 15:31:52 GMT
From:      new@thrush.cfmu.eurocontrol.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   RIP source code

Does anyone know where I could get the source code to RIP ?

I don't have external FTP access but I can mail to servers.

All help would be greatly appreciated.

Thanks.

Dennis Newport, Tel. +32 2 729 9621
e-mail: new@cfmu.eurocontrol.be


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 15:35:43 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Mult. Class C on one physical network?

In article <321vcq$nm7@noc.usfca.edu> sanner@noc.usfca.edu (David J. Sanner) writes:
>I am going to be setting up a Cisco router with multiple ethernet
>segments.  I am wondering if I can have multiple Class C network
>numbers on the same segment/physical-network ?

Yes, you can configure this on the Cisco with the secondary-address option.

>If I can do this:
>- What problems might I encounter with two or more hosts on the same physical
>  network having different class c broadcast addresses?

Machines on one logicla net will see broadcasts intended for the other net.
If they forward them you may create broadcast storms.

>- Will the router try to answer arp requests for hosts trying to send
>  to another host on the same physical net but in a diff. class C network?

Hosts shouldn't send ARP requests for destinations not on their own
network, so this shouldn't come up.

>I have heard of sites putting two subnets on the same physical network.
>The problems I have heard with that is that is that the router can  
>can answer a ARP request for a host so that any IP packets traveling
>from host A to host B (Hosts A and B are in different subnets
>but share the same physical network) travels from host A to the
>router and then back to host B thus doubling the network traffic.

That's the expected behavior.  With TCP/IP, communication between subnets
normally goes through a router, even if the subnets are on the same
physical medium.  With some operating systems there are ways to force
direct communication, but the default behavior is to go through the router.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 16:20:30 GMT
From:      bearbj@crash.cts.com (Brian S. Jones)
To:        comp.protocols.tcp-ip
Subject:   pacbell isdn

Anyone have any experience connecting to the internet using ISDN from Pac Bell?

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 00:44:36 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.protocols.tcp-ip
Subject:   RE: FTP'able Protocol Analyzers

There is one available from the university of Delft.

It can be gotten at dorm.rutgers.edu
I think the directory:

/pub/msdos/wattcp/delft

--Mike

The programs are called: the gobbler and the beholder.


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 17:59:38 GMT
From:      gsarff@wicat.com (Gary Sarff)
To:        comp.protocols.tcp-ip
Subject:   Redirect to another IP address

I am testing some software prior to purchase and have discovered a
problem, but I don't know the terminology for this particular behaviour
and have not been able to find it in an RFC. (obviously looking in
the wrong place)

What happens is, when I type on my SUN
 ftp some.site

the ftp client writes:
  trying  xxx.xxx.xxx.xxx

and nothing happens for a bit, and then it writes

  trying  yyy.yyy.yyy.yyy   (y address <> x address)

and then connects and displays the ftp login prompt.

I assume machine xxx or the DNS redirected the client to machine yyy?
Is this correct?  How is this done, and what is this behaviour called?

I ask because when I try this same thing using the potential vendor's
software it trys xxx and then just sits there forever and never 
tries machine yyy.
Also, does anyone know off hand of some ftp site that is set up to do
this now, that I can test against?  I was testing using such a site
but apparently they have changed their setup and so it doesn't do
this redirect anymore, and I need one to test against so I can complain
to the vendor and show the vendor an example.  
Thanks much.


-- 
  []   (the null signature)

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 22:02:25 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: LCS-8634 Network cards; any info?

In article <776344523snz@cellar.demon.co.uk>
           ash@cellar.demon.co.uk "Andrew Hardie" writes:

>I have "inherited" half a dozen rather smart looking network cards.
>They are marked LCS-8634 and certainly *look* like Ethernet cards.

Yes, they are made by Longshine and are NE2000 compatible.  I've
got two, one in each of my two PCs.  They work fine with WfWG 3.11
Netware Lite, NetBEUI, TCP/IP-32 Winsoc.dll, Newt, PC-TCP etc.

>Does anyone know anything about these, the switch settings and
>which packet driver to try?

The switch settings are manual-only, but give you a wide choice, 
IRQ 3,4,5,9,10,12,15;  base memory c800 to de00; remote boot ROM
etc.

>I tried the NE2000 driver at the usual settings (IRQ3, I/O 300h)
>and it locked up. The cards appear to have DMA jumpers; don't
>rememeber seeing an NE2000 with those.
 
>I expect they'll turn out to be Arcnet or something :-(

No, true blue Ethernet.... (you should have guessed from the AUI
and the BNC connector!)

Send me a message or call me if you want a copy of the main pages 
from the manual, giving settings; and the distribution/driver disk.


Phil R.
-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Aug 1994 23:00:00 +0000
From:      mark@marks.demon.co.uk (mark snowdon)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   None (mail relay)

.ibmpc
Subject: Exelan EXPORT 2000 config info wanted please
Message-ID: <776457889snz@marks.demon.co.uk>
Date: Tue, 09 Aug 94 18:44:49 GMT
Organization: Myorganisation
Reply-To: mark@marks.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.29
Lines: 13

I have an Exelan terminal server model export 2000 (8 port), it has an AUI
socket on it to plug into a tranceiver & 8 x 25D RS232 ports.
When I switch it on the first port becomes 'live', but I haven't a clue
how to set it up to talk to my IBM6150, (do you have to send a code to get it
into command mode???).
I would be troolie :-) grateful for any info on this item.

PS. I'm also after an ethernet board for my NCR 700 tower. This would also
be made by Exelan and have a multibus 2 connector.

If I've posted to the wrong group, please accept my humble appologies.
-- 
mark snowdon

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      8 Aug 1994 23:47:05 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Redirect to another IP address


In article <1994Aug8.175938.18133@wicat.com>, gsarff@wicat.com 
(Gary Sarff) writes:
|I am testing some software prior to purchase and have discovered a
|problem, but I don't know the terminology for this particular behaviour
|and have not been able to find it in an RFC. (obviously looking in
|the wrong place)
|
|What happens is, when I type on my SUN
| ftp some.site
|
|the ftp client writes:
|  trying  xxx.xxx.xxx.xxx
|
|and nothing happens for a bit, and then it writes
|
|  trying  yyy.yyy.yyy.yyy   (y address <> x address)
|
|and then connects and displays the ftp login prompt.
|
|I assume machine xxx or the DNS redirected the client to machine yyy?
|Is this correct?  How is this done, and what is this behaviour called?

Probably what happened was that the DNS returned two or more 
IP addresses for "some.site".  Your FTP client tried connecting
to the first, timed out, then tried connecting to the second 
address and succeeded.

I don't know of any "redirect" feature that works as you describe
(though it might be a nice addition to the protocol suite.)

|I ask because when I try this same thing using the potential vendor's
|software it trys xxx and then just sits there forever and never 
|tries machine yyy.

Yeah, this sounds like what I call substandard software.  RFC-1123
("Host Requirements - Applications") states the following in re
"multihomed hosts" (which is the inelegant term applied to hosts 
with more than one interface):

   2.3  Applications on Multihomed hosts

      When the remote host is multihomed, the name-to-address
      translation will return a list of alternative IP addresses.  As
      specified in Section 6.1.3.4, this list should be in order of
      decreasing preference.  Application protocol implementations
      SHOULD be prepared to try multiple addresses from the list until
      success is obtained.  More specific requirements for SMTP are
      given in Section 5.3.4.

Thus, the software you are evaluating would appear to be violating
a SHOULD (though not a MUST).

|Also, does anyone know off hand of some ftp site that is set up to do
|this now, that I can test against?  I was testing using such a site
|but apparently they have changed their setup and so it doesn't do
|this redirect anymore, and I need one to test against so I can complain
|to the vendor and show the vendor an example.  

If you have control of your DNS server, you could just create
a temporary host name something like this:

dummy.yourdomain.	in  a	1.2.3.4	; an address that doesn't work
			in  a   1.2.3.5 ; an address that does

Then see how FTP (or TELNET, or rlogin, or whatever) to 
"dummy.yourdomain" works.

Unfortunately, although RFC-1123 has been around for almost 5 years,
it seems that there's still a lot of software around that isn't up
to snuff.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 00:17:50 GMT
From:      paulo@PROBLEM_WITH_INEWS_GATEWAY_FILE (Paulo Menezes)
To:        comp.sys.sun.hardware,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Ethernet controllers for SUN workstations?

Vidar Vetland (vidar@drue.unit.no) wrote:

> We are doing some measurement experiments of TCP/IP performance over
> an Ethernet. We would like to know which kinds of controller that can
> be put inside a Sun workstation. In particular we would like to know
> which controllers that Sun Microsystems itself put into the
> workstations they sell.
 
> If possible we would also like to get some pointers to relevant
> documentation and/or technical specifications.
 
> Thanks in advance.
 
> Vidar Vetland
> Politecnico di Milano, Italy
> Email: vidar@elet.polimi.it

Try http://www.sun.com/
--
------------------------------------------------------------------------------
Paulo Menezes                     |   IIIII           SSS   RRRRR
Institute of Robotics and Systems |     I            SS     R   RR
University of Coimbra             |     I          SS       R   RR
Largo Marques de Pombal           |     I          SS       RRRRR
3000 Coimbra - Portugal           |     I         SS        R   RR
E-Mail: paulo@dee.uc.pt           |   IIIII    SSS          R    RR
------------------------------------------------------------------------------

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 01:05:11 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RIP source code

In article <NEW.94Aug8173153@thrush.cfmu.eurocontrol.be> new@thrush.cfmu.eurocontrol.be (Dennis Newport) writes:
>Does anyone know where I could get the source code to RIP ?
>
>I don't have external FTP access but I can mail to servers.
> ...

Buy a CDROM drive and then spend less than $50 for a CDROM of all of
one of the BSD UNIX distributions.  Walnut Creek sells more than one.
O'Rielly sells 4.4BSD-Lite.  Then you'll have not just `routed`, but
`route`, and `query`.

I think Walnut Creek also sells CDROM's with RFC's, if that is
what is really desired.


Vernon Schryver    vjs@rhyolite.com

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 09:17:45 -0400
From:      wenhui@news.cs.columbia.edu (Wen-Hui Luo)
To:        comp.protocols.tcp-ip
Subject:   Problem in binding a socket to a specific IP addrees.

Hi,

I have a question on how to bind a specific IP address to a socket.
Given the following:

	int sd;
	struct sockaddr_in localAddr;

	sd = socket(...);
	
	bzero(&localAddr, sizeof(localAddr));

	localAddr.sin_port = ...;
	localAddr.sin_family = AF_INET;
	localAddr.sin_addr.s_addr = inet_addr("9.2.46.53");
	
	bind(sd, (struct sockaddr *) &localAddr, sizeof(localAddr));

	...

Then I tried to use FD_SET, select(), FD_ISSET to see if I receive any
packet.  However, this doesn't work.  But once I change
inet_addr("9.2.46.53") to INADDR_ANY, it works.  Can anyone explain
this please?  

Thanks.

Kevin.






	

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 10:41:30 -0400
From:      rdippold@qualcomm.com (Ron "Asbestos" Dippold)
To:        news.announce.newgroups,news.groups,comp.protocols.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.networking.tcp-ip
Subject:   2nd CFV: comp.protocols.smb

                          LAST CALL FOR VOTES (of 2)
                     unmoderated group comp.protocols.smb

Newsgroups line:
comp.protocols.smb      SMB file sharing protocol and Samba SMB server/client.

Votes must be received by 23:59:59 UTC, 18 August 1994.

After this CFV appears on news.announce.newgroups it will be sent to
the mailing list samba@listproc.anu.edu.ai (Samba mailing list).

This vote is being conducted by a neutral third party.  For voting
questions only contact rdippold@qualcomm.com.  For questions about the
proposed group contact Tom Haapanen <tomh@metrics.com>.


CHARTER

comp.protocols.smb is for discussions about the use of the SMB
protocol, its applications and compatability, and for the discussions
about SMB-based server and client software, such as Samba.

There is currently no Usenet newsgroup for discussions about the use
of the SMB networking protocol, or for discussions about SMB-based
software packages.  This protocol is increasing in popularity and
deserves a proper home.

The SMB protocol is used by software such as Microsoft LAN Manager,
IBM LAN Server, Windows for Workgroups, Windows NT and the upcoming
new version of Windows, "Chicago."  It provides services for name
services, disk sharing, printer sharing and browsing.  It can run on
top of Netbeui, IPX/SPX, and, more importantly, TCP/IP, making it a
versatile protocol with capabilities exceeding those of NFS.

It has been argued that SMB is not a protocol; however, the official
SMB specifications (available by FTP from ftp.microsoft.com) call it
"SMB FILE SHARING PROTOCOL".  This certainly makes it as much of a
protocol as, say, NFS (in comp.protocols.nfs).

There is currently available a free (using the GNU Public License)
implementation of and SMB server and client, Samba, developed by
Andrew Tridgell at the Australian National University in Canberra,
Australia.  With the added availability of the free TCP/IP protocol
stack (for Windows) and client software (for MS-DOS and OS/2) from
Microsoft, SMB becomes a versatile yet inexpensive alternative to NFS
for Unix/Windows/MS-DOS internetworking.

There is now in existence a mailing list for Samba and SMB
discussions, hosted at the Australian National University.  This
mailing list has been growing in both membership and traffic, and the
time has come to make the transition into a newsgroup.  Currently the
mailing list has over 400 subscribers (not including those served by
remote mail exploders), with increasingly heavy traffic.  The Samba
ftp site also gets 200-400 connections per week.

While Samba is expected to be the most popular topic of discussion,
all other SMB-related discussions will also be welcome.


HOW TO VOTE

Send MAIL to:   voting@qualcomm.com
Just Replying should work if you are not reading this on a mailing list.

Your mail message should contain one of the following statements:
      I vote YES on comp.protocols.smb
      I vote NO on comp.protocols.smb

You may also ABSTAIN in place of YES/NO - this will not affect the outcome.
Anything else may be rejected by the automatic vote counting program.  The
votetaker will respond to your received ballots with a personal acknowledge-
ment by mail - if you do not receive one within several days, try again.
It's your responsibility to make sure your vote is registered correctly.

One vote counted per person, no more than one per account. Addresses and
votes of all voters will be published in the final voting results list.



comp.protocols.smb Bounce List - No need to revote
------------------------------------------------------------------------------
steve@trinidad.ISI-AutoNet1.Com                                   Pavlov's Cat
tsukada@gaken.dnp.co.jp                                          TSUKADA Seiji


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 04:24:28 GMT
From:      russo@shell.portal.com (Russo and Hale)
To:        comp.protocols.tcp-ip
Subject:   Multiple Stacks and routing

This is probably a basic question and in the faq, but here goes...
If I load KA9Q to route from PPP to Ethernet, and I load an additional
stack on the ethernet card in the same computer (running LWP for Dos on
the additional stack), will KA9Q route packets from PPP to the LWP, as well
as the KA9Q?  Do I need two separate addresses? 

It may seem dumb to do such a thing, but I need LWP for my
WordPerfect email gateway...

Am I better off with two machines?

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 09:38:21
From:      dhennon@xray.indyrad.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   IP vs. LAT, what to do?


     Two days ago I was asked to put two old VMS machines on our network. They 
communicate via LAT, and would be the first such devices on our network to use 
LAT to communicate.  I was immediatly overcome by an ill feeling, and a wave 
of sickness swept over me. 
     Why do I feel this way? I seem to have the opinion that Good Things come 
to those who use IP, and Bad Things happen with LAT. But, why? Just what are 
the advantages of using IP instead of LAT, or LAT instead of IP? Do I have a 
well-founded reason for my feelings, or not? 

     This is not meant as a flame, or meant to start a flame fest, I'm just 
interested in facts.

Grover Browning
I.U. Radiology
gcbrowni@foyt.indyrad.iupui.edu

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 11:36:43 -0400
From:      francis@avalle.insoft.com (John [Francis] Stracke)
To:        comp.protocols.tcp-ip,news.admin.misc
Subject:   Re: CIX to restrict Internet access

In article <naran.776018355@sfu.ca>, Travers Naran <naran@fraser.sfu.ca> wrote:
>weave@hopi.dtcc.edu (Ken Weaverling) writes:
>>This could get real ugly.
>
>You said that right!  But if we all keep our heads and just ignore CIX if they
>continue the activities you describe above, they won't survive long.  

You cannot ignore the CIX.  A *huge* fraction of the Net routes
through it.  And it, or something like it, is needed: before the CIX
came along (early 1991, I think), the only way for a commercial
provider to get full connectivity was to make several (which would now
be dozens) of bilateral agreements with all the other providers (and,
of course, if they don't take you seriously, they don't have to make
any agreement at all).

People are talking as if the CIX were some evil nasty group sitting
there blocking off the traffic of the Net.  But it's not a blocker,
it's a router.  It's just decided to become more selective about who
it routes for.

Refresher of what the CIX is: it's a combination trade association and
collapsed backbone.  Members get to connect to the CIX router in San
Jose (? and also one other on the East Cost, I think).  Members are
obliged to accept traffic from other members and their customers (but
see below).  Members are not obliged to accept traffic from indirect
customers of other members, nor from direct customers who are IP
resellers; i.e., if I set up FrancisNet, selling IP in Mechanicsburg,
connect to, say, Sprint (which is a CIX member), and I do not join the
CIX myself, then CIX members are not obliged to accept traffic from me
or my customers.  This, I think, is intended to make sure that the CIX
doesn't get beaten up by traffic from people who aren't supporting it.
(Insert PBS-pledge-drive-style guilt trip here.  ;-) The CIX is not a
trade cartel; anybody who can come up with the $10K (a very small
amount for a truly viable business) can join.

History: initially, the CIX didn't block anybody; they wanted to give
the broadest connectivity they could.  However, they didn't have good
connectivity to the ANS-connected nets; the only way at that point to
get commercial connectivity to ANS was to buy it from ANS CO+RE or
from somebody who'd made a bilateral agreement with them.  At some
point, once the CIX had emerged as The Way to get commercial
connectivity, ANS and the CIX embarked on a trial connection, but ANS
was still not a CIX member.  About a year ago, the CIX decided to
block off some or all of ANS's traffic (I don't remember the details),
so ANS became a full-fledged CIX member, and their direct customers
received CIX connectivity.  However, so did their indirect customers,
customers of providers who were connected to ANS CO+RE.  Many of these
providers were not CIX members (and we're not just talking Ma-and-Pa-
KettleNet; amazingly enough, att.net is [or was] connected through ANS
CO+RE and is not [or was not] a CIX member).

Finally, the CIX board decided it could no longer go on providing
routing to the world for free.  Among other things, the CIX is still
T1, and it needs to move to faster technologies, for which it needs
money.  Also, the fact that individual CIX members were free to block
non-members or not meant that, effectively, the CIX was selectively
enforcing the membership requirement, which could open them up to
anti-trust litigation.

Disclaimer: all this is my understanding, distilled from a few years
of following com-priv@psi.com (requests to com-priv-request, and give
them a few days; it's done by hand--and God help you if you send them
to the list ;-).
-- 
|John (Francis) Stracke | My opinions are my own. | PGP public key available |
|InSoft, Inc.           |====================================================|
|Mechanicsburg, PA      |  Almost no one has ever wanted a 1/4" drill bit;   |
|francis@insoft.com     |   all they ever wanted was a 1/4" hole.            |

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 12:01:17 -0400
From:      crucker@access.k12.wv.us
To:        comp.protocols.tcp-ip
Subject:   routing IP on netware server with 3 segments


I need details on brigde configuration in the autoexec.ncf to load and bind IP 
to the lan boards.  The server has three network boards.  the concentrators are 
segmented. The router is on one segment.  I need to forward ip to the other 
segments.  I have a 3 byte internet network address.  I also need details on 
Host, network, profile, etc config files.
			Please help, I'm desperate!

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 05:56:11 GMT
From:      sysman1@un.seqeb.gov.au (The Fantom Ferret)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp

Data Business Forms wrote:
|Is there any way to automate FTP?  What I want to do is the following:
 
|	Have a user type a command -- eg: transfer   -- and have ftp open a 
|session with a unix host and transfer the files to the host, and then 
|close the session and quit ftp.
 
|	All without the user knowing what is going on.  A batch file really.
 
|Any and all responses will be greatly appreciated.

Your best bet would be to get the "Expect / Tcl" package. It is designed to
automate the operation of interactive programs such as FTP.

You can Expect/Tcl/Tk from ftp.cme.nist.gov:/pub/expect

--
Graeme Wightman (GW211) - System Support  Email: ferret@alfalfa.seqeb.gov.au
South East Queensland Electricity Board	  Fax:   +61 7 2217556
GPO Box 1461, Brisbane 4001 AUSTRALIA	  Phone: +61 7 2234150

             <<< GOD is REAL .... unless declared INTEGER >>>

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 14:38:23 -0500
From:      matt@ibmoto.com (Matt Ragan)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet

>Can anyone point me to a version of telnet (source if poss) which 
>supports scripting, a bit like comms programs for PCs do?

There are two fairly easy ways that I can think of off of the top
of my head:

You could use a recent version of C-Kermit (I think that all versions
of C-Kermit 5A have it), which supports both scripting and telnet
connections.

Alternatively, you could use 'expect', which you can use to put complex
scripts around virtually anything that is text-based, including telnet.
It even comes with examples of using telnet in scripts.

Each of these two have their own advantages and disadvantages.  Kermit
is fairly easy to compile and doesn't have any dependencies, but its
scripting capabilities are limited to telnet/modem communication, etc.
Expect requires TCL (which you can get where you get expect), but it
a more generic scripting package.

-- 
--------------------------------------------------------------------------
Matt Ragan  (matt@ibmoto.com)  Motorola/IBM Somerset PowerPC Design Center
Network Administrator          Systems/Network Engineering  (512) 795-7298
9737 Great Hills Trail         Austin, Tx  78759        FAX (512) 795-7519
--------------------------------------------------------------------------

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 12:04:40
From:      timc@sni.com.au (Tim Cullen)
To:        comp.protocols.tcp-ip
Subject:   TCP to COM Port Listener

Is there any software using Winsock V1.1 that will listen to a 
predefined TCP/IP port number and redirect input/output to/from a predefined 
COM port ?This would allow a user to remotely connect to a modem on another 
persons PC using something like COMt.

I know that most terminal servers come with a listener service that will 
support this function.

Also is there the equivalent software for Unix and Windows NT ?

Thanking you in advance.
Regards,

Tim Cullen (timc@sni.com.au)
Siemens Nixdorf Information Systems Pty Ltd
655 Pacific Highway, St Leonards, NSW, 2065, AUSTRALIA
Voice: +61-2-430-2154, Fax: +61-2-439-5734

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 13:27:52
From:      ag129@ucs.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.tcp-ip
Subject:   List of TCP header options?

Is there a list of TCP header options anywhere?  I'd expect it to
be in Assigned Numbers but it's not.  I know there are several RFCs
which add new options.

Also is there a way to find out whether an option you don't know
about is of 'case 1' (single byte) or 'case 2' (length field), like
the facilities field in X.25?  Or are all new options 'case 2'?

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 10:01:50 GMT
From:      bortz@cnam.cnam.fr (Stephane Bortzmeyer)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: TCP connection problem and how to interpret netstat output?

In article <31j1co$815@sheckley.cnam.fr>, bortz@cnam.cnam.fr (Stephane Bortzmeyer) writes:

>I have a strange TCP problem on a DEC Alpha + OSF/1 server. The machine 
>is an HTTP server (http://web.cnam.fr/) and has an important load 
 [...]
>The symptom is the following: [...] very often we see delays of 10, 20, 
>40 seconds and often Mosaic times out.
 [...]
>I tried to investigate with netstat and lsof. At peak hours, netstat 
>typically sees 200 connections, more than the half of them being in 
>TIME_WAIT. lsof sees typically 40-60 descriptors open, which means 
>15-20 clients, the average number of simultaneous transfers.

Well, I cannot pretend we solved the problem (it appears quite complicated 
and DEC's support was helpless) but we have now an apparently working configuration. I cannot say what is the important parameter because we 
had to make the server work and couldn't spend too much time trying one 
parameter after the other. 

We set MAXUSERS in the kernel to a reasonable value (512!), used the 
"linger" option in the program (forcing a process to wait the flushing 
of the output queue, thus allowing our load control mechanism to work 
fully) and patched the kernel to increase the size of the listen queue. 
This last one appears to be the important thing: the problem completely 
disappeared (but I cannot be *positive*, rough calculation indicate that 
the queue should *almost never* be full). See a discussion on 
comp.unix.programmer "Increase the socket listen queue?" for details.

To patch the kernel:

# dbx -k /vmunix
(dbx)   patch somaxconn=16
   
Don't forget to modify SOMAXCONN in <sys/socket.h> for your applications 
which use it.

I re-read RFC 793 which specifies TCP (recommended reading, it's quite 
clear, and you can complete with Comer's "Internetworking with TCP/IP". 
netstat seems to use the same state names as the RFC. But the problem 
doesn't appear to be related with a maximum number of sockets being 
reached because it occurs whatever the number of connections is.

See the Web page:
http://www.cnam.fr/Network/Infosystems/Tools/tcp-http-problem.html for 
a complete story. 
 
Thanks to <Bernhard.Schneck@Physik.TU-Muenchen.DE>, Mike Iglesias 
<iglesias@draco.acs.uci.edu>, Steve Peltz <peltz@cerl.uiuc.edu> and 
Mary Walker <walker@zk3.dec.com> for help and explanations. Come to 
see our server http://web.cnam.fr/ now :-)
 
Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
bortzmeyer@cnam.fr            Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

http://web.cnam.fr/personnes/bortzmeyer/home_page.dom



-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 11:11:48 GMT
From:      chris@quay.ie (Christopher Davey)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Linking 2 IP Subnets via SNA (SUMMARY)



Thanks to all who responded to my request for information about
connecting IP subets via SNA. It took a while, but here is a summary
of the responses I received.

Chris
---


From: Per Weisteen <Per.Weisteen@hda.hydro.com>
Subject: Re: Linking 2 IP Subnets through SNA
Organization: Norsk Hydro, Hydro Data, Norway
Date: Wed, 20 Jul 94 10:38:00 PST
X-Mailer: WinVN 0.90.5
Status: RO

Yes, you can link IP subnets thru an SNA net. You need a suitable
IBM comm box with IP-support (IBM 3172 or IBM 3745 or similar).
An IBM rep (with TCP/IP knowledge) should be able to tell you
what you need.

Per W. 

---

Date: Tue, 19 Jul 94 01:33:06 EDT
From: "Robert A. Rosenberg" <hal9001@panix.com>
Subject: Re: Linking 2 IP Subnets through SNA
To: Christopher Davey <chris@quay.ie>
X-Mailer: VersaTerm Link v1.1.3
Status: RO

Yes you can connect two IP subnets via an SNA network. One way (which is not
the only way) of doing this is via the use of an IBM product called TCP/IP
for MVS. This requires the use of IBM Mainframes to provide access to the
SNA Network. The connection has IP subnet#1 talking to IBM Mainframe#1 which
uses a MVS TCP/IP function called SNALINK to map the IP connection onto the
SNA network. SNALINK#1 then sets up an Appl-to-Appl session with SNALINK#2
running on Mainframe#2 which then talks to subnet#2. The IP networks can be
connected to the IBM Mainframes via a number of different boxes including
the use of a Front End Processor (FEP) such as a 3745 (which is the box used
to handle the SNA network). 

A reference source on how to do this is:
    Integrating TCP/IP into SNA
              by
    Ed Taylor
              from
    Wordware Publishing
    ISBN:1-55622-340-4
    $24.95 


---

From: bdbauer@dal.mobil.com (Blaine D. Bauer)
Subject: Re: Linking 2 IP Subnets through SNA
Date: Mon, 18 Jul 1994 12:39:03
Message-Id: <bdbauer.124.000CA70A@dal.mobil.com>
content-length: 0
Status: RO

>Does anyone know whether it is possible to link 2 IP subnets
>through a SNA network. If so, what it required ?

IBM has a cheap bridging program called LAN-to-LAN-WAN; it should 
only be used if low-volume is desired.  For higher volumes Harris-Adacom has 
a good TCP/IP-over-SNA router.

>The machines at each end are Windows NT machines. 

You might consider SNA server; I don't know if it does this.

>Is it possible to tunnel IP through using PPP or somesuch ?

It won't be PPP; it would have to be something proprietary since its not 
running on an asynch line.  SNA is not a point-to-point network!


-------------------------------------------------------------------------------
Blaine D. Bauer         214-951-4489                  BDBauer@Dal.Mobil.Com

---

Date: Fri, 15 Jul 1994 02:14:17 -0500
From: "Milton D. Miller II" <miltonm@bga.com>
Message-Id: <199407150714.CAA21835@ghostwheel.bga.com>
To: chris@quay.ie
Subject: Re: Linking 2 IP Subnets through SNA
Newsgroups: comp.unix.aix,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip
In-Reply-To: <1994Jul14.153305.4420@quay.ie>
Organization: Real/Time Communications - Bob Gustwick and Associates
Cc: 
Status: RO

IBM has solutions using PCs as routers and one using 6000s is
in beta test.  Contact your marketing rep for more information.

milton
--
Milton Miller  KB5TKF  miltonm@bga.com  miltonm@austin.ibm.com
I never speak for IBM



-- 
----WNA----------------------------------------------------------------------
Chris Davey                       Internet: chris@quay.ie
Quay Financial Software           Phone   : +353 1 6612377 Fax: +353 1 6607592
The views expressed above do not necessarily reflect those of my employer

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 22:59:00 -0700
From:      mrubin@libre.com (Martimus)
To:        misc.consumers.house,comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.networking
Subject:   Re: advice on tcp-ip cable and telephones sought

>In article <31ot0h$e6i@steele.ohsu.edu>, Milton Hill <hillm@ohsu.edu> wrote:
>Hi - A quick question about wiring my new house:
>If I go with a catagory 5 10BaseT/UTP cable to make
>a small tcp/ip network can I do the following - 
>The cable is 4 pair, I would like to run phone
>signal over 1 pair and network over the others.
>Does anyone think there would be a problem with
>inter ference?
>
>Thanks
>Milt
>hillm@ohsu.edu

Probability is that there WILL be interference from the Voice circuit.  What 
do you do if you ever decide to add a second voice circuit?  Also, how do plan 
to break out the appropriate pairs to feed a hub? not to mention feeding ma 
bell.  Considering that you will be running 100Mbps wire for use in a 10Mbps 
application, it might not be a problem to use the last pair of the wire but I 
don't recommend it. 

  For piece of mind, it would be better to pull separate wire (level 2 (if you 
can find it) and level 3 are cheap these days, level 5 is NOT).  Also, be sure 
to use GOOD wall plates and professional installers (level 5 loses it's rating 
when pairs are substantially un-twisted to install in wall plates).


Good luck,


Martin
mrubin@libre.com

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 12:00:17 GMT
From:      gvrooij@ms.philips.nl (Guido van Rooij)
To:        comp.os.ms-windows.networking.tcp-ip,comp.unix.bsd,comp.protocols.tcp-ip,comp.os.386bsd.questions
Subject:   Re: SLIP->BSDI V1.1->Digiport->Winsock Problem

In article <Cu82K1.AEG@newera.ab.ca>,
Donald L. Gover <dlgover@newera.ab.ca> wrote:
>I've been working on getting a slip line brought using winsock and a BSDI
>
>  Dose anyone have any ideas? Also is there anyproblem running slip througth
>the digiport box? I thought that maybe the digiport box might not like to run
>binary data so I set up a uucp link and that worked with out error. 
>

Are you sure you are using hardware flow control (RTS?CTS) and *not* 
software flow control?

>  Thanks don...
>

-Guido

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 12:30:00 GMT
From:      bauer@ds (Daniel Bauer)
To:        comp.protocols.tcp-ip
Subject:   Multicast TP (RFC 1301) ?

IP Multicasting is unreliable. MTP is a proposal for a reliable
multicast service that can be placed on top of IP multicastig.
MTP is described in RFC 1301

I am looking for information concerning MTP. I only now the RFC.
Are there other papers about MTP available?
Does anybody know if an implementation of MTP (RFC 1301) exists?


Thanks,

Daniel

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 13:02:47 GMT
From:      bhaskar@brtph181.bnr.ca (Shaji Bhaskar)
To:        comp.protocols.tcp-ip
Subject:   Any vendors of TCP (without IP)?

Hi folks,

We are considering running TCP directly on a LAN, without IP.  We are
using a proprietary kernel on 680X0 processors, but may move to a
commercial kernel.

I think I will be out of luck on this one, but are there any vendors
out there that sell a TCP implementation we could use?

Am I stuck with customizing BSD source, or are there better
alternatives?

Shaji Bhaskar
BNR, Research Triangle Park
North Carolina 27709
-- 
----------------------------------------------------------------------------
Shaji Bhaskar                                             bhaskar@bnr.ca
BNR, Research Triangle Park, NC 27709, USA                (919) 991 7125

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 00:58:36 -0700
From:      wesc@snoopy.cs.ucsb.edu (Wesley J. Chun)
To:        comp.protocols.tcp-ip
Subject:   TCP DEADLOCK Problem

Hi,

I am working on distributed simulations of asynchronous network protocols.
I am currently facing a problem which no one has been able to assist me
with so far.

I am writing some asynchronous code where each side of a TCP connection
will arbitrarily read and write to the socket independent of each other.
However, if the TCP input buffers on both sides fill up while both sides
are in the middle of a write(), then both sides will block, pending
enough space in the buffer to transfer more data (which will never hap-
pen), thus resulting in a deadlock.

The first solution I came up with meant marking both sockets as non-
blocking, however, this applies to the reads as well as the writes, so
my select() call falls through on the reads, which I don't want it to.
I only want non-blocking writes.  The other problem is that even on a
non-blocking write, I will get an error saying that the socket would
block, but then message handling is difficult because it is in the
middle of an event-driven system.  We can't just drop the packet!

The second solution involved creating a PAIR of TCP socket connections
where one would be for reads (and writes from the other side) and vice
versa.  However, this could still result in a deadlock.  It would just
take a little longer than the original scenario.

A solution that another person came up with would prohibit writing to
the TCP connection simultaneously, but since both sides are asyncho-
nous and the reads and writes are independent of each other, this is
impossible.

One of my colleagues recommended alternating between reading and
writing to the socket, but this suffers from the same problem as
the previous solution.

Is there anyway I can avoid this problem?  Or can I?  If you can help
out soon, that would be greatly appreciated.  Thanks!


Wesley Chun (wesc@cs.ucsb.edu)

------------------------------------------------------------------------
"A computer never does what you want... only what you tell it."

**** Wesley J. Chun ****		Department of Computer Science
*** wesc@cs.ucsb.edu ***		College of Engineering
** (415) 917-8235 hme **		2106 Engineering I, Box 46
** (805) 893-7275 lab **		University of California
** (805) 893-8553 fax **		Santa Barbara, CA  93106-5110
------------------------------------------------------------------------

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 14:50:54 GMT
From:      prabha@ctron.com (V. Prabhakar)
To:        comp.protocols.tcp-ip
Subject:   Limited vs Directed broadcast

Hello everyone,

I have question regd IP broadcast. Suppose if we represent the IP address as:

	{ <network no>, <subnet no>, <host no> }

how does { -1, -1, -1 } ie, 255.255.255.255 differ from { -1, subnet #, -1 }.
Is the latter a limited broadcast or is it direct broadcast directed towards
the subnet. Please clarify. I am using  RFC 1122 (pg 30) as reference.

Thanks,

V Prabhakar

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 15:08:53 GMT
From:      landmark@cs.tu-berlin.de (Torsten Kerschat)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast TP (RFC 1301) ?

bauer@ds (Daniel Bauer) writes:

>I am looking for information concerning MTP. I only now the RFC.
MTP is a research item at the Technische Universitaet Berlin
and the Universitaet Bremen. To improve robustness and scalability,
the specification has been modified. It is called now MTP-2.
An implementation of MTP-2 is running in user-mode and as
kernel driver for Solaris 2.x. We are now beginning to
improve the robustness and performance of the implementation.

Torsten
-- 
Torsten Kerschat - Interdepartmental Research Center for Process Control
		   Technical University of Berlin (PRZ - Room HE 104)
Internet: torsten@prz.tu-berlin.d400.de / landmark@cs.tu-berlin.d400.de
Phone   : ++49 / (0)30 / 314 - 26822    Fax: ++49 / (0)30 / 314 - 21114

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 15:40:47 GMT
From:      jim@reptiles.org (Jim Mercer)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun <-> AS/400

In article <mhymanCu0ynG.8Ap@netcom.com>, Mike Hyman <mhyman@netcom.com> wrote:
>We might be doing just this and I am looking for any input
>in the following areas:
>
>1. Standard TCP utilities like rcp, ping, etc. Do they work the same?

the as400 (V2R3) has support for the following:
telnet (outgoing session in linemode, vt100 and 5250 (maybe 3270)
telnetd (incoming sessions can be linemode, vt[12]00, 3270 and 5250)
ping
ftp/ftpd
lpd/lpr
smtp

they work pretty much the same, except that the AS/400 is a block/record
oriented system and Unix is character based.  the directory structures
on the AS/400 are different than those on Unix.

>2. NIS/NIS+ do these exist on the AS/400 and can the AS/400 be
>part of a specific domain, with a master server onSolaris?

i doubt this very much.
i haven't seen any indication that the AS/400 is going this way.

>3. How does NFS perform, we are looking at transferring up to
>2GB of data nightly with NFS, am I crazy??

i beleive that there is an NFS server implementation for the AS/400, but
not client (ie. you can advertise the AS/400 disk, but the AS/400 cannot
mount your Unix disk.)

>4. EBCDIC to ASCII issues. When doing file transfers are the file
>contents translated properly.

the translations are fine, and you can change the translation map if
you wish.

as of V2R3, there is a 16,000,000 byte limitation on ftp file transfers.
(yes, 16 million, not 16 meg.)

>5. E-Mail. Does the AS/400 handle SMPT e-mail at all??

it does do incoming and outgoing SMTP, however, it has some odd broken bits.
most of the problems are with aliasing and mapping FQDN's to 8 char tokens
for routing.

>6. FDDI. We will be connecting the Sun and AS/400 together over
>FDDI, is this too new to work properly, again any issues??

i believe there is an FDDI card for the AS/400.  i don't know if you can run
TCP/IP across it though.

some other notes:

i have been working with the AS/400 TCP/IP for a couple years.  each new
release has suprised me tremendously, both in performance, as well as
the addition of facilities.

the next release V3R0, is supposed to have incredible expansions on
performance, as well as increased facilities.

also, rumor has it that a version of the AS/400 is coming which will support
both OS/400 and AIX at the same time.
-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416 506-0654 ]
[      "'Tis better to clutch a glowing squid than curse the darkness."       ]
[                                                     Archie McPhee Catalog   ]

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      09 Aug 1994 16:13:17 GMT
From:      Roberto.Shironoshita@mail.csd.harris.com
To:        comp.protocols.tcp-ip
Subject:   Re: A good idea for internet developer's !

In article <Cu37FH.5MH@dpcsys.com> dan@dpcsys.com (Dan Busarow) writes:

> JParadis (jparadis@courrier.usherb.ca) wrote:
> > I would like to see a client server product that could give the
> > geographical
> > location of an I.P. addresse. And it would be great to find it for
> > Macintosh,
>
> whois works just fine if you have it.  Just give it the network portion 
> of the address, 132.210 in your example, and you can get back the 
> street address etc.. for the organization it is registered to.  
>
> % whois 132.210
> Universite de Sherbrooke (NET-USHERB-NET)
>    2500 Boulevard Universite
>    Sherbrooke, Quebec, J1K 2R1
>    CANADA
>
> That's as close as you are going to get since the NIC doesn't have 
> address data on individual hosts and IP addresses have nothing to do 
> with geography.

Not really.  For example:

$ rwhois -h rs.internic.net ccc.ccc.ccc
Infonet (NET-INFOLANnn)
   2100 E. Grand Avenue
   El Segundo, CA 90245

   Netname: INFOLANnn
   Netnumber: ccc.ccc.ccc.0

   Record last updated on 17-Apr-92.

The InterNIC Registration Services Host ONLY contains Internet Information
(Networks, ASN's, Domains, and POC's).
Please use the whois server at nic.ddn.mil for MILNET Information.

The network number I have blanked out is one of those assigned to Infonet,
which seems based in California.  The physical network is in Europe.  I
know because our site in Camberley, UK is plugged in there.
--

------------------------------------------------------------------------------
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
            opinion or policies of Harris Computer Systems.

        In-Real-Life:   Roberto Shironoshita
                        Harris Computer Systems
        Internet:       Roberto.Shironoshita@mail.csd.harris.com
        UUCP:           ...!uunet!mail.csd.harris.com!Roberto.Shironoshita

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 16:17:09 GMT
From:      anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala)
To:        comp.protocols.tcp-ip
Subject:   MAC Layer

Hi folks,
	 In my lab two machines are connected by ethernet, token ring and fddi.
And hence, each one has three ip addresses, say hname-en, hname-tr, hname-fd.
Now, when I send a tcp packet from hname1-en to hname2-en, is it possible that
the packet travels on any of the above three? or should it go on ethernet only?

Thanks 

anil gurijala



-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 16:27:30 GMT
From:      ussw@netcom.com (Don Dunstan)
To:        comp.protocols.tcp-ip
Subject:   Re: Any vendors of TCP (without IP)?

Shaji Bhaskar (bhaskar@brtph181.bnr.ca) wrote:
: Hi folks,
 
: We are considering running TCP directly on a LAN, without IP.  We are
: using a proprietary kernel on 680X0 processors, but may move to a
: commercial kernel.
 
: I think I will be out of luck on this one, but are there any vendors
: out there that sell a TCP implementation we could use?

You might wish to consider USNET from U S Software.  It is designed for
real-time, embedded systems.  And, it may be used with any kernel --
customer or commercial.  More information is available by anonymous
ftp to ftp.netcom.com (pub/ussw).

TCP is defined with IP dependencies.  USNET isolates these dependencies
so that it is possible to eliminate the IP layer.  However, something
would need to take its place (handle the functions normally handled by
IP).


-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 16:33:37 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple host mail - how?


In article <326bjp$9dc@crl.crl.com>, stevel@crl.com (Steven Lawson) writes:
|I am writing an SMTP gateway for my companies TCP/IP package and am unclear
|on something.  How is configuration usually handled which allows users
|to specify a domain (say foobar.com) and have the mail properly arrive
|at different hosts? (say, john@foobar.com and jane@foobar.com end up
|going to john@sales.foobar.com and jane@support.foobar.com)
|
|Is this somehow done with the DNS records, or am I missing a configuration
|file?  Everything else works to this point, but I am unclear how other
|sites are handling the above situation.

Figuring out how to deliver the mail based on the contents of the
mailbox portion of the address is a function of an "alias" or
"forwarding" database on the host that initially receives the mail.
For example, if FOOBAR.COM were a VMS+PMDF host, then the commands
$ MAIL
mail> SET FORWARD/USER=JOHN "IN%""john@sales.foobar.com"""
mail> SET FORWARD/USER=JANE "IN%""jane@sales.foobar.com"""
would cause its mailer to route the mail to john and jane properly.

Now, making sure that the mail GETS TO foobar.com is, of course, 
a function of the DNS.  There should be one or more A and/or 
MX records for foobar.com pointing to some host(s) that
will accept its mail.  (And, of course, the receiving mailer
needs to be taught that it IS foobar.com.)

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 94 16:34:47 GMT
From:      fr@sunbim.be (Farid Rahmi)
To:        comp.protocols.tcp-ip
Subject:   Class B routes "incompatible" with Class C subnet masks ?


Hello,


Due to overflowing routing tables filled up with Class C routes I am wondering 
if it is allowed to define a Class B (static) route on a Class B machine that 
has a Class C subnet mask ?


e.g. : HOST -> 141.253.1.1		Class B host
	 SN -> 255.255.255.0		Class C subnet mask

       ROUTE -> 165.1.0.0		Class B NET route
		      ---

My question is not really how this can be implemented, but rather why this
can/should not work (as we experienced), preferrably backed up by some solid 
paperwork (RFC,etc...).

Thanks for any feedback,

Farid. 




-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Aug 1994 19:00:34 GMT
From:      grobecke@alkaid.crd.ge.com (Andrew Grobecker)
To:        comp.protocols.tcp-ip
Subject:   RPC and Windows/MAC clients


                    unsubscribed
j–



d subject

        












bscribed
























bscribed











    














ities   
        












-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 18:47:06 +0200
From:      root@rmi.de ( most western town of Germany)
To:        comp.protocols.tcp-ip
Subject:   Q: cslip 2.7 panics SunOS 4.1.3, mget/mfree problems ?

Help !
We're running (well trying to :-) cslip 2.7 under SunOS 4.1.3. Installation
and configuration are easy and without errors. Getting it up and logging in
(from various other 'slips') is no problem but transferring files with
ftp for example crashes the sun. The 'panic' messages is mostly 'mget' and
sometimes 'mfree', 'adb -k' on the kernel dump reveals no futher info since
the crash happens at different places in the kernel.
Yes, we have applied patches 100567-04 and 100587-01 (which are identical)
but this doesn't help.
Anybody out there with similar experiences and/or solutions ?

Regards,

R. Mohr

-- 
--
 Rupert Mohr              | rmohr@rmi.de         | Free space for future
 RMI GmbH, D52016 Aachen  | dl3no@dl3no.ampr.org | enhancements

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 00:01:24 GMT
From:      tlw@mercury.ncat.edu
To:        comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Problem with NFS and FDDI


The systems and servers in our computer center are connected to a 
Cabletron MMAC box using FDDI, the workstations in one of our labs
are connected  using ethernet thin wire to a 3COM Netbuilder II,which has 
a FDDI interface and 6 BNC connections,  when I connect the MMAC to the
Netbuilder using thin ethernet everything works fine, BUT when I connect
them through the FDDI connections everthing but NFS works, any attempt
to access the NFS mounted disk results in a "server not responding" message.
The systems are DECsystem 5000's and the workstations are DECstation 5000's.

Can anyone give me an idea why the NFS connections don't work, any possible 
solutions would be greatly appreciated.

Please respond to: tlw@garfield.ncat.edu
-- 
Timothy Wilder
North Carolina A&T State University
Department of Electrical Engineering
1601 East Market Street

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 94 00:47:47 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: A good idea for internet developer's !

In article <BILLW.94Aug6230600@glare.cisco.com>, billw@glare.cisco.com (William ) writes:
> We've had semi-joking customers mention that SNMP-readable GPS receivers
> in our routers would be a nice thing...

Make it SNMP-WRITABLE, so that when I'm rearranging a network I can
set the latitude and longitude and have the router teleport itself to
its new location (or to Cisco's repair centre :-).

========================
Tom Evans  tom@wcc.oz.au
Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170
Victoria, Australia 61-3-561-9999  FAX ...560-0067  A.C.N. 004 818 455


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 00:59:29 GMT
From:      mgleason@cse.unl.edu (Mike Gleason)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp

various wrote:

||Is there any way to automate FTP?  What I want to do is the following:
||	Have a user type a command -- eg: transfer   -- and have ftp open a 
||session with a unix host and transfer the files to the host, and then 
||close the session and quit ftp.
 
||	All without the user knowing what is going on.  A batch file really.
 
|Your best bet would be to get the "Expect / Tcl" package. It is designed to
|automate the operation of interactive programs such as FTP.

If all you want to do is FTP a file or two, you can use ncftp's "colon-mode."
E.g.  "ncftp cse.unl.edu:/pub/mgleason/ncftp/ncftp.tgz"

--
______________________________________________________________________________
mike gleason                 mgleason@cse.unl.edu             NCEMRSoft, baby!

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 01:36:44 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: Problem with NFS and FDDI

tlw@mercury.ncat.edu wrote:
: a FDDI interface and 6 BNC connections,  when I connect the MMAC to the
: Netbuilder using thin ethernet everything works fine, BUT when I connect
: them through the FDDI connections everthing but NFS works, any attempt

It might not be what first leaps to my mind, but a very common
situation centers around IP fragmentation.

Here is one experiment to further diagnose things - use a mount size
of 1024 bytes when you perform the NFS mounts. If everything works
then it is likely that your FDDI<->Ethernet interconnect device does
not fragment IP datagrams. 

You could also try reducing the IP MTU on the FDDI systems (if
possible) to 1500 bytes, or use something like netperf to try and send
largeish UDP datagrams from the machines on FDDI to the machines on
Ethernet. You could also leave the mounts as they are any only try to
access files that are "small" (< Ethernet MTU - try 1024).

At that point, you have a couple of options.

1) Get your interconnect vendor to upgrade you to a device that does
   IP fragment. This IP Fragmentation should include proper handling
   of IP datagrams that have the "DF" or Don't Fragment Bit set.

if they won't/can't you can then

a) get that vendor to take back their equipment and refund your money.
   take that money and us it to buy an interconnect device that does
   IP fragment properly.

-or-

b) Reduce your FDDI MTU to 1500 bytes if you can and take the
   FDDI<->FDDI Performance hit which has been discussed in
   comp.dcom.lans.fddi.

-or-

c) Re-do all the mount commands on every system mounting the FDDI
   servers to use a mount size of 1024 bytes.

-or-

d) wait for your system vendor to come-out with a version of
   NFS/UDP/IP that can do PathMTU discovery even in the presence of
   interconnect devices that do not provide ICMP Error messages (if it
   doesn't fragment, it probably doesn't do ICMP) Given that in this
   instance the systems in question are "old" DEC 5000's I'd bet that
   it is unlikely - unless DEC upgrades Ultrix to include PMTU, or you
   can drop BSD onto the boxes. Also, I don't know of any
   implementation of PTMU that works without the ICMP messages. 

rick jones
speaking only as rick jones...

and people wonder why Vernon S. and I keep "ranting" about bridges that
don't IP fragment...

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 14:03:32 -0500
From:      Mike.Blansfield@mailgw.er.doe.gov
To:        comp.protocols.tcp-ip
Subject:   ODIPKT crashes DOE PC's.

     We have experienced a VERY strange problem here at DOE Headquarters. 
     We have been using Daniel Lanciani's odipkt shim to run tcp/ip and ipx 
     concurrently over Novell's odi.  We have had no problem with that 
     until Monday.  All of the sudden machines with that shim loaded 
     started locking up hard.  We have a Cisco AGS that we recently 
     upgraded but that was a week before we started experiencing problems. 
     People using Novell LAN Workplace for DOS (and Windows) have no 
     problem.  We also have a 3Com packet driver that is stable but they 
     only have it for their 3C509 board.  The version of the shim we are 
     using is 2.1 but I downloaded the latest 3.0 with the same results. 
     Has anybody out there experienced this or anything like it?
     
     Please help!
     
     Thanks in advance,
     
     Mike
     
     ********************************************************************** 
     Michael G. Blansfield       Email: root@oerhp01.er.doe.gov
     Senior Systems Engineer     cc:Mail: mike.blansfield@mailgw.er.doe.gov 
     CDSI/DOE - Energy Research  X.400: /s=blansfield/g=mike/c=us 
     Germantown, MD                     /admd=attmail/prmd=usdoe/o=er 
     Phone: (301)903-0339
     FAX:   (301)903-7363               Isn't mail fun! 
     *********************************************************************

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 07:55:45 GMT
From:      albertk@cs.kun.nl (Albert Koppes)
To:        comp.protocols.tcp-ip
Subject:   IPPROTO_RAW under Solaris sockets ?

In testing some network configuration I have built a small program 
for spoofing some ICMP packets using IP_RAW sockets, under Solaris 2.3 . 

Using the socket(AF_INET,IP_RAW,IPPROTO_RAW) end 
sendto() this works fine for putting packets on the network. 
Now I want to read raw IP datagrams addressed to my machine, (so not in promisc. mode ).

I do not understand that using the socket for reading with the same 
family,type and protocol and using recv(s,....) this does not work ? 
Is that due to the multiplexing ?

If I go up a level and read from the socket on the IPPROTO_ICMP level, 
it works and the ping I use to test it is answered too. ( By the way, 
does the fact that I am able to read the packet  _and_ that it is being 
processed mean that the datagram is copied here ? )

It is not really clear to me if I need to go to down to DLPI/streams to
 read packets from the network. In "TCP/IP illustrated"(Stevens) it is 
mentioned that for Solaris you would need to do this as front end to all 
network monitors, but in this case I don't need to go to the data-link level.

I would be grateful if somebody could point out an example of network 
monitoring or RAW_IP programming in Solaris 2.3.

Thanks in advance for all advice,

Frank Zeppenfeldt
A


-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 10:56:39 GMT
From:      bos@surfnet.nl (Erik-Jan Bos)
To:        comp.protocols.tcp-ip
Subject:   Re: Class B routes "incompatible" with Class C subnet masks ?

Farid Rahmi (fr@sunbim.be) wrote:

> Due to overflowing routing tables filled up with Class C routes I am 
> wondering 
> if it is allowed to define a Class B (static) route on a Class B machine 
> that has a Class C subnet mask ?
>
> e.g. : HOST -> 141.253.1.1		Class B host
> 	 SN -> 255.255.255.0		Class C subnet mask
>
>        ROUTE -> 165.1.0.0		Class B NET route
> 		      ---
> My question is not really how this can be implemented, but rather why this
> can/should not work (as we experienced), preferrably backed up by some solid 
> paperwork (RFC,etc...).

I think I am not quite sure what you mean by a "Class B machine" in this
context, but my feeling is that you want to aggregate routes of multiple
class C size subnets out of a class B. If that is what you want, I do not
think there is a problem.

It is also possible to aggregate multiple class C networks into
supernets, using CIDR technology.

Please remember that the world *is* classless, so to speak, with CIDR
being around. The official notation of a class B network now is:

Oldspeak: 141.253.0.0 is a class B
Newspeak: 141.253.0.0/16

The number behind the network number defines how many bits there are in
the subnet. E.g., 192.87.0.0/17 means 128 C nets in old speak starting
with 192.87.0.0 up till 192.87.127.0.

The 127 C nets in the above example will use only one routing table
entry: 192.87.0.0/17.

You can read more about this in the following documents:
- RFC1467
- RFC1517
- RFC1518
- RFC1519
- RFC1520

Hope this helps.

--
Erik-Jan.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 00:29:56 -0800
From:      Wan_Tjoa@smtp.esl.com (Wan Tjoa)
To:        comp.protocols.tcp-ip
Subject:   Re: pacbell isdn

In article <karl.33.00124B1B@cavebear.com>, karl@cavebear.com (Karl
Auerbach) wrote:

> 
> >Anyone have any experience connecting to the internet using ISDN from Pac Bell?
> 
> Yup.  I've got one into my house for net access.
> 
> I've got the Combinet 160 bridge and I keep the B channels up 24 hours a day 
> if I can.
> 
> It works quite well.  (But I wish I had a T-1.)
> 
> The cost is pretty reasonable because I'm on a Centrex arrangement.  
> Otherwise the penny a minute + 4 cents to bring up a connection would get 
> tiresome.
> 

Approximately how much is the Combinet 160 bridge and the Centrex
arrangement?

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 13:42:02 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject:   Re: Problem with NFS and FDDI

In article <329avc$ee2@hpindda.cup.hp.com> raj@cup.hp.com writes:
>tlw@mercury.ncat.edu wrote:
>: a FDDI interface and 6 BNC connections,  when I connect the MMAC to the
>: Netbuilder using thin ethernet everything works fine, BUT when I connect
>: them through the FDDI connections everthing but NFS works, any attempt
>
>It might not be what first leaps to my mind, but a very common
>situation centers around IP fragmentation.
>
>Here is one experiment to further diagnose things - use a mount size
>of 1024 bytes when you perform the NFS mounts. If everything works
>then it is likely that your FDDI<->Ethernet interconnect device does
>not fragment IP datagrams. 
> ...

Another, sometimes easier diagnostic aid is `ping -s 4096 etherclient`
on the FDDI NFS server.  If that does not work, and if both computers
do the right things with large ICMP Echo-Requests, the problem is in
the wires (i.e. the bridge).

Note also that just reducing the mount size ("rsize=1024") will not
solve problems NFS has with bridges that don't IP fragment, since rsize
doesn't affect reading large directories.


Vernon Schryver    vjs@rhyolite.com

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 14:12:37 GMT
From:      clarwr@aur.alcatel.com (Randy Clark - 6441)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with NFS and FDDI

>The systems and servers in our computer center are connected to a 
>Cabletron MMAC box using FDDI, the workstations in one of our labs
>are connected  using ethernet thin wire to a 3COM Netbuilder II,which has 
>a FDDI interface and 6 BNC connections,  when I connect the MMAC to the
>Netbuilder using thin ethernet everything works fine, BUT when I connect
>them through the FDDI connections everthing but NFS works, any attempt
>to access the NFS mounted disk results in a "server not responding" message.
>The systems are DECsystem 5000's and the workstations are DECstation 5000's.
>
>Can anyone give me an idea why the NFS connections don't work, any possible 
>solutions would be greatly appreciated.
>

I inherited a very similar network environment. Our FDDI-based servers are configured
to have an MTU of 1500. I was told this is because the Netbuilders don't handle
IP fragmentation well (if at all). 3Com says they do as of software revision 6.2.
But that's the software on the boxes I inherited and so far I have been unable to
find any reference to IP fragmentation/reassembly in the 3Com docs.

I know, it kind of defeats the purpose of having FDDI when you chop up the packets
into ethernet-sized bites...and when I get confirmation one way or the other that
will change!

If anyone responds to Timothy's query, please copy me. I don't have much 
experience with the 3Coms and would be very interested in knowing if I'm
chasing the wrong culprit.

**********************************************************************
Randy Clark, Sr. Telecom Specialist |  "Good ballplayers make
Alcatel Network Systems             |       good citizens."
email: clarwr@aur.alcatel.com       |            - Chester A. Arthur
**********************************************************************



-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      9 Aug 1994 22:57:07 +0930
From:      simon@wraith.internode.com.au (Simon Hackett)
To:        comp.protocols.tcp-ip
Subject:   Re: Redirect to another IP address

gsarff@wicat.com (Gary Sarff) writes:

>  trying  yyy.yyy.yyy.yyy   (y address <> x address)
 
>and then connects and displays the ftp login prompt.
 
>I assume machine xxx or the DNS redirected the client to machine yyy?
>Is this correct?  How is this done, and what is this behaviour called?

Sounds like the site has a host name which has multiple address ("A")
records associated with it. In other words, the machine is connected to
multiple physical networks, and the network address on each
physical cable is listed against the host name.

My network has a few hosts like that because we run two independent
links into the Internet and some of my hosts are on "both" networks,
and are listed in the DNS with two IP addresses in just this way.

>I ask because when I try this same thing using the potential vendor's
>software it trys xxx and then just sits there forever and never 
>tries machine yyy.

Sounds like a possible bug in the vendors' software, but not one that
would be noticed very often.

SImon
-- 
      Simon Hackett,  Internode Systems Pty Ltd, Adelaide, Australia
      simon@internode.com.au   Ph +61 8 373 1020  Fax +61 8 373 4911

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 12:55:12 +0100
From:      robjan@rabo.nl (Rob Janssen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP multicast

In <Cu0n65.Aov@tridom.com> mwr@eng.tridom.com (Mark Reardon) writes:

>RFF 1112 discusses Multicast IP over ethernet and the use of the
>MAC Multicast addresses. Has any work been done on Token Ring
>networks? The equivalent to Multicast there is called Groups but
>I have received several warnings that most devices can't handle 
>MAC Group addressing. Should I just use the C000 FFFF FFFF broadcast
>address? Inquiring minds want to know.

Check RFC1469

Rob

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 22:58:37 -0500
From:      hagler@worf.infonet.net (SirMark)
To:        comp.dcom.modems,comp.dcom.servers,comp.protocols.ppp,comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Multi-user PPP?

Greetings, Salutations, and all those good things...

I've been asked by the superintendent of our schools to give Internet
demonstrations/lessons to people of the school/community, and I need some
suggestions of how to go about some equipment problems.

What I want to do is get three terminals active over one dial-up link.  I
live in the middle of Nebraska, so direct access to the Internet isn't an
easy option to turn to.  We're using, for the most part, dial-up access
through commercial providers or the University.  I have a PPP account, and
with that account I can have three telnet sessions open at once over the
PPP connection.  The computer I use has a 14.4K v.42bis modem on COM1, and
has COM2-4 free.  The school has a few Kimtron KT7-PC terminals in the back
room, and I'd like to use them so that I can get more than one person
online at once.  Is there any way to get each of the three telnet sessions
that are open over PPP to re-direct to another COM port?  The modem is
COM1, and I want to get the first PPP window to be directed to COM2, the
second to COM3, and the third to COM4.  I know the speed of the connection
will be limited, but we're not being billed for online time, and we're not
doing any big jobs, such as downloading files and FTP.  Mainly, we use
services such as mail, usenet, gopher, wais, and www.  Is there a PPP
application for DOS (or Windows, or if we have to, Mac) that allows us to
do this?  Any help would be appreciated.  Also, if we can't accomplish this
task with the COM ports and terminals, I have access to a Novell network in
the computer lab, and if anyone has suggestions on how to accomplish this
over a LAN, please contact me as well.

Thanks a lot for any help you can give.

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 15:01:48 GMT
From:      kent@unx.sas.com (Paul Kent)
To:        comp.protocols.tcp-ip
Subject:   Re: programming problem with tcp/ip sockets (bind())

In <32amb5$ks0@hasle.oslonett.no> leister@oslonett.no (Wolfgang Leister) writes:



>Hello
>
>We have got some programming problems with tcp/ip.  Maybe somebody could
>help. 
>
>We have been writing a communication library using tcp/ip sockets.  We
>are using the calls as explained in W.R.Stevens' network programming
>book.  Everything is working as expected, except when we exit some
>application program, restart it and listen on the same port with the new
>program.  Then it might happen that the bind() call returns -1 with
>errno=EADDRINUSE.  When we build in a repetition of this bind()-call
>then about 12 times we get EADDRINUSE and thereafter EINVAL.  When we
>wait about 1 minute between exit() and restart everything goes fine. 
>
> Some more observations:
> - It does not matter whether we close/shutdown the sockets properly
>   or just exit
> - We tried to connect to this port/server before calling bind()
>   (in the hope that this would clean up something).  It did not affect
>   anything. 
> - This problems appears both on sun and hp machines (at least)
>
>short sketch of our program:
> int ls = socket();

/*TRYME*/ int r=1;
/*TRYME*/ setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, (char*)&r, sizeof(r));

> if (bind(ls,...) == -1) {
>    repeat bind(ls,...) until success;    // success does never happen :-(
> }
> listen(ls,...);
> etc. etc.
>
 
> It would be great if somebody could give us a hint, how to avoid
>this problem.

The TCP protocol requires the wildcard socket remains "valid" until
all clients have closed their ends of the connections and some timeout
passes. (thats probably a gross generalization :-0, but it is what
is tricking you up in all likelyhood)

the reuseaddr socket option took care of the problem for me in a
similar situation. try the two lines marked TRYME above.

Hope that helps.

Paul






--

Paul Kent (Base SAS R&D)              " nothing ventured, nothing disclaimed "
kent@unx.sas.com              SAS Institute Inc, SAS Campus Dr, Cary NC 27513.

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 11:54:51 +0200
From:      roque@master.di.fc.ul.pt (Pedro Roque Marques)
To:        comp.protocols.tcp-ip
Subject:   Re: Any vendors of TCP (without IP)?

Shaji Bhaskar (bhaskar@brtph181.bnr.ca) wrote:
: Hi folks,
 
: We are considering running TCP directly on a LAN, without IP.  We are
: using a proprietary kernel on 680X0 processors, but may move to a
: commercial kernel.
I'm sorry ... but could you explain why you want sutch a thing ?
tcp is a Tranport Protocol over the Network Protocol IP .... 
can hardly be maped on a Data Link Layer i guess ...   
but i dont see the advantajes of this . and there are a lot of problems:
without a Network Protocol you don't have routing 

: I think I will be out of luck on this one, but are there any vendors
: out there that sell a TCP implementation we could use?
 
: Am I stuck with customizing BSD source, or are there better
: alternatives?
 
: Shaji Bhaskar
: BNR, Research Triangle Park
: North Carolina 27709
: -- 
: ----------------------------------------------------------------------------
: Shaji Bhaskar                                             bhaskar@bnr.ca
: BNR, Research Triangle Park, NC 27709, USA                (919) 991 7125
-- 

	Pedro Roque (roque@di.fc.ul.pt)

	<a href="http://www.di.fc.ul.pt/~roque"> Home Page </a>

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 20:15:29
From:      dmelczer@eniac.seas.upenn.edu (David Z. Melczer)
To:        comp.protocols.tcp-ip
Subject:   Linux and SLIP

Has anyone gotten a SLIP link running under Linux 1.0.9 (slackware) with Xfree 
2.1.1 installed?  What modules do I need?  Any help would be appreciated.  


Thanks in advance.

-Dave Melczer
dmelczer@eniac.seas.upenn.edu


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 16:34:21 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: IP vs. LAT, what to do?


In article <dhennon.5.0009A3F1@xray.indyrad.iupui.edu>, dhennon@xray.indyrad.iupui.edu writes:
|
|     Two days ago I was asked to put two old VMS machines on our network. They 
|communicate via LAT, and would be the first such devices on our network to use 
|LAT to communicate.  I was immediatly overcome by an ill feeling, and a wave 
|of sickness swept over me. 
|     Why do I feel this way? I seem to have the opinion that Good Things come 
|to those who use IP, and Bad Things happen with LAT. But, why? Just what are 
|the advantages of using IP instead of LAT, or LAT instead of IP? Do I have a 
|well-founded reason for my feelings, or not?

I dunno; perhaps your mother was frightened by a multicast service 
advertisement packet when you were in her womb.

Psychological exegesis aside, there are various pros and cons of 
using LAT vs. IP (I assume that you mean here TELNET or rlogin).  Seems
to me that this was all hashed out here about 6 months ago.

Quick recap:

Network layer:
LAT has none.  To use LAT between point A and point B, you must have
a MAC-layer (bridged) LAN between the two.
Advantage: IP

Transport layer:
LAT has fixed retransmissions at 1-second intervals.  Default timeouts
are appallingly small (I strongly recommend that, if you use LAT, you
boost all timeouts to the max[*].)  TCP has very sophisticated, robust
flow control/retransmission.
Advantage: IP

Host CPU loading:
LAT bundles data up by (client/server) CPU pairs and sends it out on
a tunable strobe (circuit timer).  TELNET usually sends data one packet
per screen/keystroke (though some clients will accumulate input data
and send it out on a timer).  Thus, LAT usually uses fewer packets than
IP and therefore saves host CPU resources.  Also, because LAT is a 
shorter stack than TCP/IP, there is usually less overhead per packet.
Advantage: LAT

Network utilization:
For reasons given above, LAT usually uses fewer packets than IP and 
thus wins here.  The exception is where your network link gets 
congested (e.g. if you have a 9.6Kbps link) and LAT's stupid 
retransmission approach turns out to be too aggressive.
Advantage: LAT, usually

Support for "multihomed hosts" and "clusters":
TELNET/DNS/TCP/IP support for situations where one service name
maps to multiple network attachment points is weak at best.  Some
TELNET/rlogin clients are capable of trying multiple addresses
if the first address mapping to a given hostname fails.  In
DNS/TCP/IP there is no general facility for doing dynamic load
balancing across a service name (though the new round robin feature
in BIND 4.9.3 is a step in the right direction.)
LAT maintains up to date knowledge of reachability and loading on
all server nodes, so that at connect time the LAT client always
makes the "right" connection.
Advantage: LAT

Scalability:
Because LAT sits right on top of the MAC layer, and because its
reachability information is propagated via multicasts, LAT is 
NOT suitable for a large (>10000 node) network.  TELNET/TCP/IP,
on the other hand, is seen to work well on a >10^6 node network.
(Actually, on this point, LAT's advantages in the previous point
count against it.)
Advantage: IP

Strategic viability:
Because LAT is wedded to 802 networks, and because it's wedded
to DEC and VMS, it is doubtful (to say the least) that it will
enjoy considerable market share or platform support in the
future.
Advantage: IP.

Conclusion:
I dunno.  If it's easy for you to use LAT (let's say you've got
some old DECserver 200's that you don't want to throw away), then
use it and be happy.  Once you set it up, its maintenance is nil.
OTOH, if it would be easier for you to put TCP/IP on your VAXen,
and you'd feel more comfortable with that, then go that way.

Here at the UofA, we have dozens of LAT hosts and hundreds of
LAT connections sharing our otherwise predominantly TCP/IP network,
and everyone coexists and performs quite nicely.  So I don't think
you have any particular reason to suffer anxiety attacks.  But then,
I'm not a licensed psychologist!

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

---

[*] KEEPALIVE TIMER = 255 seconds
    RETRANSMIT LIMIT = 120 seconds
    

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 16:40:42 GMT
From:      grobecke@alkaidcrd.ge.com (Andrew Grobecker)
To:        comp.protocols.tcp-ip
Subject:   RPC and Windows/MAC clients

Hello,

I am looking into what it will take to connect Windows and MAC clients to an RPC server application.  What will I need on the client end to get RPC working and where do I get it?

Thanks,
Andy Grobecker
grobecke@thuban.crd.ge.com


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 18:36:32 GMT
From:      sab@phantom.com (Zippy)
To:        comp.protocols.tcp-ip
Subject:   "Upwards" subnet-masking

Say I have a range of 16 class C addresses: W.X.0.0 through W.X.15.0.  Is
there any reason I can't use more than 8 bits as a subnet mask (but fewer
than 13, obviously) in order to sidestep the 254-node restriction (and the
subsequent routing requirement) I would face by using 16 separate class C
addresses?

Is there an RFC which addresses this issue?

Does anyone know of any software packages which will look at the first byte,
determine that it's a class C address, and refuse to allow more than 8 bits to
be used as a host field in a subnet mask?

Please reply via e-mail to the address below.  If there's interest, I'll
summarize.

Thanks,

Seth Bromberger

--
Seth Bromberger
sab@phantom.com

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 15:56:53 +0200
From:      leister@oslonett.no (Wolfgang Leister)
To:        comp.protocols.tcp-ip
Subject:   programming problem with tcp/ip sockets (bind())

Hello

We have got some programming problems with tcp/ip.  Maybe somebody could
help. 

We have been writing a communication library using tcp/ip sockets.  We
are using the calls as explained in W.R.Stevens' network programming
book.  Everything is working as expected, except when we exit some
application program, restart it and listen on the same port with the new
program.  Then it might happen that the bind() call returns -1 with
errno=EADDRINUSE.  When we build in a repetition of this bind()-call
then about 12 times we get EADDRINUSE and thereafter EINVAL.  When we
wait about 1 minute between exit() and restart everything goes fine. 

 Some more observations:
 - It does not matter whether we close/shutdown the sockets properly
   or just exit
 - We tried to connect to this port/server before calling bind()
   (in the hope that this would clean up something).  It did not affect
   anything. 
 - This problems appears both on sun and hp machines (at least)

short sketch of our program:
 int ls = socket();
 if (bind(ls,...) == -1) {
    repeat bind(ls,...) until success;    // success does never happen :-(
 }
 listen(ls,...);
 etc. etc.

 It would be great if somebody could give us a hint, how to avoid
this problem.
 Thank you
   - wolfGang

------------------------------------------------------------------------
Dr. Wolfgang Leister, Metronor AS, PB 238, N-1360 Nesbru, Norway


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 19:55:33 GMT
From:      wchen@netcom.com (Wen Chen)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Port TCP/IP apps to X.25


Hi,

We have developed our distributed application for TCP/IP protocol.  Now, 
we need to port our code to X.25.  Our goal is to keep the change to our
code minimum it at all.

For those who are familiar with the protocol stack, do you think if we 
can approach it by pushing a TCP stream module on top of the X.25 
driver/module.  We are relatively new to this territory.  Any suggestions 
are appreciated. 

-wen



-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 20:02:48 GMT
From:      ramana@austin.ibm.com (Anand Teerth Desai)
To:        comp.protocols.tcp-ip
Subject:   does "routed" support split horizon/poison reverse/triggered updates

Does anyone know if BSD4.3/BSD4.4 versions of "routed" command
(routing protocol daemon) support Split Horizon / Poison Reverse
or triggered updates ? 

thanks, 
ramana




-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      10 Aug 1994 20:25:29 GMT
From:      sverkere@oopc7.kemi.uu.se (Sverker Edwardsson)
To:        comp.protocols.tcp-ip
Subject:   slattach for speed above 38400 ?

Perhaps a stupid question...

Does anyone out there know if it is
possible to run slattach (or equivalent) at
speeds greater than 38400 bps? When I try to
do that on Interactive UNIX v4.0, slattach
reports "unsupported speed"...

/Sverker



-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 20:47:17 GMT
From:      root@goliath.un.AtlantaGA.NCR.COM (0000-Admin(0000))
To:        comp.protocols.tcp-ip,comp.unix.programmer,comp.sys.ncr
Subject:   Binding a DGRAM (UDP) socket?


Hi,

I am having a problem with UDP sockets in the context of broacast addrs.
I am implementing a dynamic BOOTP server, and one of the problems I 
need to solve is "Which interface did the bootp request come in on?"

In our environment, bootp is being used to assign the IP addr, and as
such, the client is setting the source IP address to INADDR_ANY(0.0.0.0).
It is also setting the destination addr to broadcast, as it has no
knowledge of who the bootp server might be.

When the request comes to the server, if the server is listening on 
a socket bound to INADDR_ANY, it hears the request just fine.  However,
if I listen on a set of sockets, each bound to the addr of one of the
interfaces, I never see the requests.

Is there some way to determine which interface the datagram came in on?

Note that while a generic solution would be best (then this could be
a generic dynamic BOOTP server), I will take a solution that only works
for my particular server's system/environment.  The server is an 
NCR System 3000 running MP-RAS 2.02.01 (which means the TCP/IP is
Wollongong's WIN-TCP).

Any help will be much appreciated.  Post or email to:
	Scott.Barnhart@AtlantaGA.NCR.COM

--
Scott Barnhart
AT&T Global Information Solutions
Scott.Barnhart@AtlantaGA.NCR.COM
root@goliath.un.atlantaga.ncr.com

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 20:48:43 GMT
From:      clv2m@uvacs.cs.Virginia.EDU (Charles Viles)
To:        comp.protocols.tcp-ip
Subject:   Default timeout interval for connections.

I have been doing some timing of TCP connections to various servers around the
world, and have big spikes at 75 seconds and 90 seconds. These are pretty clearly
timeouts from the TCP service (error codes from connect() indicate this).

My questions.
  1) Is there a default timeout interval for TCP connections? 
     My gut feeling is that it is implementation dependent, but 
     I can't find anything that says this.
  2) Are 75 and 90 seconds common values? Is there any consensus on
     the appropriate timeout interval, or do TCP implementations simply 
     come wrapped with the developer's favorite shoe size as the interval?
  3) Can I reset the timeout interval to MyFavoriteValue? I have
     figured out how to do this using alarm(), but am wondering if
     there is an easier way e.g. with setsockopt() call or something.

Any is help greatly appreciated.     

-- 
+-------------------------------+--------------------------------------+
|Charles Viles                  | 229 Olsson Hall                      |
|Department of Computer Science | (804)982-2291                        |
|University of Virginia         | email: clv2m@virginia.edu            |
|Charlottesville, VA 22902      | http://uvacs.cs.virginia.edu/~clv2m/ |
+-------------------------------+--------------------------------------+

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Aug 1994 22:59:56 GMT
From:      jthill@netcom.com (Jim Hill)
To:        comp.protocols.tcp-ip
Subject:   Re: Any vendors of TCP (without IP)?

In article <1994Aug10.124600.25015@brtph560.bnr.ca>,
Shaji Bhaskar <bhaskar@brtph181.bnr.ca> wrote:
>We do require connection-oriented guaranteed service.  I personally
>would like to stick with standards as far as possible, and so go with
>TCP.  I also think it is a good idea to use TCP in case we want to add
>internet connectivity later on on.
>
>I don't understand why you say TCP is linked to IP.  RFC 793 says that
>TCP is not tied to any particular network layer, and Douglas Comer in
>"Internetworking with TCP/IP" makes the same statement.  Sure, RFC 1122
>links TCP and IP, but that document is meant for users of the TCP/IP
>protocol suite as opposed to just TCP.
>

It's not so much that TCP is linked to IP, it's that most of TCP exists
only to hide IP's nature from code that doesn't want to handle its 
penchant for dropping, duplicating, and resequencing packets.  If 
your lan and nodes always deliver packets to their destination, in sequence, 
with no duplicates, you've got essentially everything TCP's designed for.
The rest of it (routing, mostly) is supplied by the underlying transport:
TCP doesn't manage _how_ a packet gets to its destination, it just watchdogs
it to be sure things go the way they're supposed to and tries to compensate
for IP's complete lack of state.

The only other thing you might want TCP for is its congestion-control 
mechanisms, which can be improved (i.e. made less CPU and bandwidth intensive) 
quite a bit given a more tractable transport; "port" numbers are common, in 
almost every detail, to all connection-oriented protocols and most of the rest.

Jim
-- 
Jim Hill
jthill@netcom.com.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 00:20:15 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP DEADLOCK Problem

Wesley J. Chun (wesc@snoopy.cs.ucsb.edu) wrote:
: I am writing some asynchronous code where each side of a TCP connection
: will arbitrarily read and write to the socket independent of each other.
: However, if the TCP input buffers on both sides fill up while both sides
: are in the middle of a write(), then both sides will block, pending
: enough space in the buffer to transfer more data (which will never hap-
: pen), thus resulting in a deadlock.

I had to write a similar piece of code recently, and decided that I
would enable asynchronous notification (SIGIO) on the sockets. In my
main event loop I block SIGIO, remove the current entries on the
pending write queue, re-enable the SIGIO, and then start to write.
This means that the writes can be interrupted by receive events.

In the signal handler (POSIX signals btw), I check how many bytes are
queued to the socket with an ioctl. I then read that many bytes off
the socket, process them and return. If more data comes-in while I am
reading, the POSIX semantics will insure that I get another SIGIO.

The shorthand version is to *always* give precedence to read over
write.

I haven't *really* pushed on this code yet, but so far, everything
seems to be working just fine.

rick jones

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 11:32:11 -0500
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip
Subject:   Re: help please-daemon process on UNIX

In article <CuDKGB.AH1@freenet.carleton.ca>,
Lance Lu <al395@FreeNet.Carleton.CA> wrote:
>
>
>
>I am going to write an application which will run as a daemon process.
>I want to know what difference from normal process in terms of coding.
>
>Do I need to disassociate from process group or ignore terminal I/O signals?
>
>If yes, how to capture kill signals?
>
>Any advice is appreciated.

My advice would be to look in "UNIX Network Programming", by W Richard Stevens
(1990, Prentice Hall), on pages 72-84, where he discusses this very topic
(running as a daemon). If I remember correctly, when this material was being
presented at Usenix at about that time, Stevens was posting it periodically
on the net because, he said and I believe him, it was not at all well-known
or well-documented.

The topic headings are:
	close all open file descriptors
	change current working directory
	reset the file creation mask
	run in the background
	disassociate from process group
	ignore terminal i/o signals
	signals, process groups, and control terminals (revisited)
	disassociate from control terminal
	don't reacquire a control terminal
	System V inittab file
	daemon termination
	skeleton daemon
	

he shows "ignoring terminal i/o signals" as

#ifdef SIGTTOU
	signal(SIGTTOU, SIG_IGN);
#endif

since you ask about this specifically.

I think Comer's Internetworking with TCP/IP Vol 3 also talks about
running as a daemon, but I loaned my copy out yesterday (sorry).

Spencer
-- 
-  Spencer Dawkins	Internet: dawkins@bnr.ca   (214) 684-4827           -
-  "Everything I need to know, I learned reading .signatures on the net"    -

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 03:50:34 GMT
From:      harp@netcom.com (Greg Harp)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast TP (RFC 1301) ?

landmark@cs.tu-berlin.de (Torsten Kerschat) writes:

>MTP is a research item at the Technische Universitaet Berlin
>and the Universitaet Bremen. To improve robustness and scalability,
>the specification has been modified. It is called now MTP-2.
>An implementation of MTP-2 is running in user-mode and as
>kernel driver for Solaris 2.x. We are now beginning to
>improve the robustness and performance of the implementation.

PLEASE address the current multicast security issues.  To get a
synopsis of the security problems with the current multicast services
(e.g. the MBone) you might as in comp.security.unix or in the
firewalls mailing list (the address which I can provide you if
necessary).  

Many people are agonizing over the fact that the current MBone
implementation is difficult-to-impossible to support securely through
a firewall.

[See Also _Firewalls_and_Internet_Gateways_ by Cheswick and Bellovin]

--Greg
-- 
---------------Greg-Harp----------------harp@netcom.netcom.com---------------
                          Cover-Your-Ass Credo:
        Admit nothing, deny everything, and make counter-accusations.

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 15:13:25 -0600
From:      dbform@tibalt.supernet.ab.ca (Data Business Forms)
To:        comp.protocols.tcp-ip
Subject:   ftp shareware

Is there any ftp shareware available?  I am using a PC and using a 
terminal emulation program to gain access to a unix box.  I want to run 
ftp from unix to the pc and get a file from the pc's local drive (A: or 
B:).  Is there any ftp software that can do this.  Is it a tsr or not?

thx

David Wood


-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 12:58:48 -0400
From:      gwright@connix.com (Gary Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP DEADLOCK Problem

Wesley J. Chun <wesc@snoopy.cs.ucsb.edu> wrote:
>I am writing some asynchronous code where each side of a TCP connection
>will arbitrarily read and write to the socket independent of each other.
>However, if the TCP input buffers on both sides fill up while both sides
>are in the middle of a write(), then both sides will block, pending
>enough space in the buffer to transfer more data (which will never hap-
>pen), thus resulting in a deadlock.

If your implementation supports it (BSD Net/2 release), you could
use the SO_SNDTIMEO socket option to limit the time the write will
block.  As long as TCP accepts data within the interval specified
by SO_SNDTIMEO, the write continues.  If TCP blocks for more than
the limit, a partial count is returned by the send operation or
EWOULDBLOCK if nothing was transferred.  Note, this behavior means
that SO_SNDTIMEO is an inactivity timer.  The write may take longer
than the SO_SNDTIMEO value.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 13:15:19 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip
Subject:   setsockopt not working in TCP/IP for OS2

This is a pretty narrow question, so I don't know if this is the place, but...

In TCP/IP for OS/2, I want to start multiple server apps listening on the
same address/port.  Note that each server is a separate executable.

I thought I could have each executible do 
setsockopt(s,SOL_SOCKET,SO_REUSEADDR,...), but I am unsure of how to do this.

So, trying to experiment, I did:

Server prg

socket;
setsockopt(s,SOL_SOCKET,SO_REUSEADDR,temp,1);

where temp is char * with a decimal 1 in it.

rc for this give -1, errno gives 10022, which is invalid argument.

Am I missing something?  Has anyone tried to use setsockopt on OS/2?

I can sen the code (small test prg) if someone wants to see it.

Note that temp was originally an int casted to (char *), and length was 2, 
but I have tried a bunch of mutations since then.


--
Jim Brain, Embedded Systems Designer, Brain Innovations.
brain@msen.com  
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 06:55:24 GMT
From:      ewtayl01@starbase.spd.louisville.edu (Eric W. Taylor)
To:        comp.dcom.modems,comp.dcom.servers,comp.protocols.ppp,comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Multi-user PPP?

The easiest way I know to do what you described would be to run Linux on
the PC that is going to use the ppp connection.  Linux will require about
4-5 megs of ram, 90-100 megs of hard drive space.

Then you can setup ppp accounts on the Linux system as it is receiving ppp
from your provider.  You should be able to connect the PC's running a ppp
supporting winsock to the serial ports with null mode cables.

Thats a lot of work.  Its not always easy to setup PPP on your own Unix
system. And doing what I described may involve some intimate knowledge of
PPP.

Eric


-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 08:08:41 GMT
From:      mac@adied.oz.au (Mark Cook)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   reliable broadcast protocol sought

Seeking software which provides reliable (guaranteed) broadcast delivery
over Ethernet/FDDI LAN.

Regards, Mark

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 09:28:53 GMT
From:      csgoh@iti.gov.sg (Goh Cheng-Seng)
To:        comp.protocols.tcp-ip
Subject:   Which application uses UDP port 16000?

We experienced a serious broadcast storm this afternoon which, according
to our Sniffer, is caused a workstation (in anohter subnet that is not
under our control) that is continuously sending to the IP address
255.255.255.255. Both the source and destination port numbers are
identified to be UDP port 16000.

Does any of you know of any PD applications that uses that port?



-- 
Goh Cheng-Seng                |  Computer Information Systems Department
Email: csgoh@ncb.gov.sg       |  National Computer Board, Singapore 
Phone: (65)-772-0451          |  71 Science Park Drive
Fax  : (65)-778-9641          |  Singapore 0511

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 11:21:15 GMT
From:      kaczmare@aaf.alcatel.at (Kazimierz Kaczmarek)
To:        comp.protocols.tcp-ip
Subject:   Any TLI SW for Dos, Win or OS/2 ?

Hi !
We are looking for info on TLI software for Dos, Win or OS/2 platforms.
BTW, who & what is the best info source on the Transport Layer Interface ?
Thanks,
Kazimierz


           V            Kazimierz Kaczmarek  (Dipl.-Ing.) Tel: +431 29121 324
+---------------------+ Senior Design Engineer            Fax: +431 2921 452
| A  L  C  A  T  E  L | Business Communications        10741::APL_KACZMARE (ANS)
+---------------------+ Alcatel Austria AG  <Kazimierz.Kaczmarek@aaf.alcatel.at>
     A U S T R I A      Ruthnergasse 1-7,  A-1210 Vienna, Austria, Europe






-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 11:37:58 GMT
From:      bhaskar@brtph181.bnr.ca (Shaji Bhaskar)
To:        comp.protocols.tcp-ip
Subject:   Re: Any vendors of TCP (without IP)?

In article <jthillCuCD7w.4v4@netcom.com> jthill@netcom.com (Jim Hill) writes:

>It's not so much that TCP is linked to IP, it's that most of TCP exists
>only to hide IP's nature from code that doesn't want to handle its 
>penchant for dropping, duplicating, and resequencing packets.  If 
>your lan and nodes always deliver packets to their destination, in sequence, 
>with no duplicates, you've got essentially everything TCP's designed for.
>The rest of it (routing, mostly) is supplied by the underlying transport:
>TCP doesn't manage _how_ a packet gets to its destination, it just watchdogs
>it to be sure things go the way they're supposed to and tries to compensate
>for IP's complete lack of state.

I agree that TCP's complexity is mostly to make it work on unreliable
networks. 

Our lan is actually a proprietary, point-to-point network with
multiple links between nodes.  It is not a conventional Ethernet-like
medium.  It drops packets and reorders them.  That is why there is a
need for a TCP-like protocol.

>The only other thing you might want TCP for is its congestion-control
>mechanisms, which can be improved (i.e. made less CPU and bandwidth
>intensive) quite a bit given a more tractable transport; "port"
>numbers are common, in almost every detail, to all connection-oriented
>protocols and most of the rest.

Another reason why I favor TCP is that it is the de-facto standard.
It also keeps open the option of adding IP and being fully compatible
at some future time.

>Jim Hill
>jthill@netcom.com.

-Shaji.
-- 
----------------------------------------------------------------------------
Shaji Bhaskar                                             bhaskar@bnr.ca
BNR, Research Triangle Park, NC 27709, USA                (919) 991 7125

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 12:40:40 GMT
From:      jasonh@chineham.euro.csg.mot.com (Jason Haar)
To:        comp.protocols.tcp-ip,comp.infosystems
Subject:   What ever happened to whois++?

Says it all really. Is whois++ still been developed, or has X.500 won the 
day in the White Pages (-type) front?

--

Cheers,

Jason
+------------------------------+------------------------------------------+
| Jason Haar, European SysAdmin   Phone: + 44 (256) 790111                |
| Motorola Cellular Subscriber      Fax: + 44 (256) 790519                |
| Basingstoke, Hampshire                                                  |
| RG24 0GY,  ENGLAND           Internet: jasonh@chineham.euro.csg.mot.com |
+------------------------------+------------------------------------------+

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 00:35:03 -0700
From:      jbartley@teleport.com (John Edw. Bartley)
To:        misc.consumers.house,comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.networking
Subject:   Re: advice on tcp-ip cable and telephones sought

>In article <31ot0h$e6i@steele.ohsu.edu>, Milton Hill <hillm@ohsu.edu> wrote: 
> If I go with a catagory 5 10BaseT/UTP cable to make a small tcp/ip 
> network can I do the following - The cable is 4 pair, I would like to 
> run phone signal over 1 pair and network over the others.
> Does anyone think there would be a problem with interference?
Well, you COULD run you phone on the last pair, wires 7 & 8, since 10BaseT
uses 1&2 and 3&6 .... 
but when your central office rings your lines, there's 90-115v AC running
through 7&8, right next to your data.  Might be a bit NOISY when that 
happens.
Suggest you do two wire pulls at the same time, one for phones and one for
the LAN.  # years from now, you might need 100Mb/s, and may regret not
having all four pairs (as some 100BaseT types need).

-- 
jbartley@teleport.COM  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at (503) 220-1016 (2400-14400, N81)

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 13:00:40 GMT
From:      vidar@elet.polimi.it (Vidar Vetland)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Controlled load on network and on machines connected to the network

Up till now we have conducted measurement experiments during data
transfer over an Ethernet using TCP/IP. All experiments were done
using unloaded workstations and an unloaded Ethernet (decoupled). In
other words, we have investigated the best case for varying parameter
settings for the TCP/IP protocol.

Now we would like to load the Ethernet and/or the workstations in a
CONTROLLED way to investigate to which degree the performance of the
data transfer deteriorates.

Is there anybody out there that can suggest a SYSTEMATIC way to load
an Ethernet and/or the communicating workstations. Any tools around?

Thanks in advance.

Regards,
Vidar Vetland
Politecnico di Milano, Italy.
Email: vidar@elet.polimi.it

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 14:22:15 GMT
From:      mgb722c@rs730.gsfc.nasa.gov (Myron Bradshaw)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: Controlled load on network and on machines connected to the network

In <32d7do$8od@ugle.unit.no>, vidar@elet.polimi.it (Vidar Vetland) writes:
>Up till now we have conducted measurement experiments during data
>transfer over an Ethernet using TCP/IP. All experiments were done
>using unloaded workstations and an unloaded Ethernet (decoupled). In
>other words, we have investigated the best case for varying parameter
>settings for the TCP/IP protocol.
>
>Now we would like to load the Ethernet and/or the workstations in a
>CONTROLLED way to investigate to which degree the performance of the
>data transfer deteriorates.
>
>Is there anybody out there that can suggest a SYSTEMATIC way to load
>an Ethernet and/or the communicating workstations. Any tools around?

Vidar,

I would suggest trying a Lanalyzer of some sort if you have one. Most LAN
analyzers support traffic generation at a specific rate (10%, 20%, etc.) If you
don't have one of these at your disposal, I'm not sure what alternatives you 
have. Anyone else with any ideas?

Myron

*************************************************
*  Myron Bradshaw - Facility Manager                            *
*  Curtis Management Company, Inc.                               *
*  NASA/Goddard Space Flight Center                             *
*  Greenbelt, MD 20771                                                 *
*  E-Mail: mgb@meb6.gsfc.nasa.gov, or                            *
*            mgb722c@rs730.gsfc.nasa.gov                           *
*************************************************
*Jesus not only saves, He also frequently makes Backups.*
*************************************************
*  Stupid TV!! Be more funny!      - Homer Simpson          *
*************************************************


-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 14:33:47 GMT
From:      al395@FreeNet.Carleton.CA (Lance Lu)
To:        comp.protocols.tcp-ip
Subject:   help please-daemon process on UNIX




I am going to write an application which will run as a daemon process.
I want to know what difference from normal process in terms of coding.

Do I need to disassociate from process group or ignore terminal I/O signals?

If yes, how to capture kill signals?

Any advice is appreciated.

Lance

-- 
*******************************************
al395@freenet.carleton.ca

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 14:53:10 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: does "routed" support split horizon/poison reverse/triggered updates

In article <CuC50p.1Cu8@austin.ibm.com> ramana@austin.ibm.com (Anand Teerth Desai) writes:
>Does anyone know if BSD4.3/BSD4.4 versions of "routed" command
>(routing protocol daemon) support Split Horizon / Poison Reverse
>or triggered updates ? 

4.3BSD-reno does all three.
Check the source at your nearest repository or CDROM.


Vernon Schryver    vjs@rhyolite.com

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Aug 1994 15:58:04 GMT
From:      mkgy@helios.rz.tu-clausthal.de (Gang Yang)
To:        comp.protocols.tcp-ip
Subject:   problem with EtherLink III


Hi,

we have a Compaq PC 486/DX 66 with EtherLink III adapter.
The netzsoftware is cutcpip 2.2TN, runs with a packet
driver 3c509.com. All pc and workstations(IBM RS/6000) in our lokal
netz are bound by a cable.

Before a week I transfered several files(about 10
MB big every file) from the compaq pc to one of the 
workstation with the command 'put' in FTP. To my 
surprise is the transfering tempo (velocity) very slow,
only about 2 Kbytes/s. In contrary, if I get the same
file on the pc from the same works. with 'get' command
in FTP, the transfering tempo is about 200 Kbytes/s.
That's a great difference! I have also tried different 
version of packet driver 3c509.com. The results keep
the same. Could anyone probably tell me, what the 
problem is? If the config.tel file is needed, let me 
know, I e-mail the file to you.

Thank you in advance!

Gang Yang 

----------------------------------------------------------------
Gang Yang     E-Mail: mkgy@sun.rz.tu-clausthal.de
Dienststelle:                       |      Home:
Institut fuer Markscheidewesen      |     
TU Clausthal, Erzstr. 18            |      Kleiner Bruch 2
Tel: 05323/72/3726                  |
             38678 Clausthal-Zellerfeld, Germany
----------------------------------------------------------------


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 16:19:09 GMT
From:      emm1@gate.net (Eric Mickelson)
To:        comp.protocols.tcp-ip
Subject:   Multicast on SunOS?

We are at an installation where PC's are using Multicast at the ethernet
level.  They are using custom software to access the ethernet card.  We
would like to access these multicast packets on  a Sun Sparc running
SunOS 4.1.3.  We have read the spec on multicast (RFC1112) and have seem
postings that indicate there is a patch  for SunOS to access multicast.
The multicast being sent by the PC's conforms  to RFC1112.

I guess the question is: Where are these patches?

--
 Eric Mickelson			e-mail: emm1@gate.net
 Lockheed Space Operations Co           emm1@pat1.ksc.nasa.gov
 KSC, FL			voice : 407-861-7509

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 18:59:39 GMT
From:      khyde@mason1.gmu.edu (Kevin J Hyde)
To:        comp.protocols.tcp-ip
Subject:   Remote Procedure Call

I am attempting to use a Remote Procedure Call across TCP/IP to
pass data between a client and server application.  The data is
going from client to server in the form of a parameter of a
remote subroutine.  (All applications are written in C.)  The
subroutine is defined as follows:

  
 extern struct test_data {
         char rtn_msg|2500|;
 } *printmessage_1();                                             
             
                                                                  
             
The client program uses the clnt_call subroutine to pass
parameters to the server.  The parameters of the remote
subroutine are encoded by the client application using the
external data representation subroutine 'xdr_wrapstring'.  They
are decoded by the server application with the same XDR routine. 
The data is returned to the client application as the value of
the printmessage  function: a 2500 byte char array.  The RPC
subroutine used to send the response back to the client is the
svc_sendreply subroutine.  I have attempted to use every XDR
routine listed in the IBM RISC 6000 documentation.  However, I
have been able to return a maximum of four bytes in every case. 
Only the first four bytes of the array are recognized.  I am
looking for a solution to return as  much data as I need.  Four
bytes is most definitely not enough for my purposes.  I need to
be able to return database query information, as well as return
codes for my application.  How can I return longer strings of
data from my remote procedure across TCP/IP?                      
                                                                  
                         

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 20:45:13 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: setsockopt not working in TCP/IP for OS2

In article <4aZIkmoZjmY0069yn@msen.com>, brain@msen.com (Jim Brain) writes:
|> This is a pretty narrow question, so I don't know if this is the place, but...
|> 
|> In TCP/IP for OS/2, I want to start multiple server apps listening on the
|> same address/port.  Note that each server is a separate executable.
|> 
|> I thought I could have each executible do 
|> setsockopt(s,SOL_SOCKET,SO_REUSEADDR,...), but I am unsure of how to do this.
|> 
|> So, trying to experiment, I did:
|> 
|> Server prg
|> 
|> socket;
|> setsockopt(s,SOL_SOCKET,SO_REUSEADDR,temp,1);
|> 
|> where temp is char * with a decimal 1 in it.

Do this instead:

	int foo;

	foo = 1;
	setsockopt(s,SOL_SOCKET,SO_REUSEADDR,(char*)&foo,sizeof(foo));

The problem is that the variable passed in must be at least as large as
the internal kernel object (an int in this case, probably 4 bytes).
This is true for both setsockopt and getsockopt.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      11 Aug 1994 22:32:36 GMT
From:      jahansen@halcyon.halcyon.com (john a hansen)
To:        comp.protocols.tcp-ip
Subject:   Tech Report Available


RE: Tech report availability
Networks Northwes Inc. is pleased to announce the availibility
of a report that will be of interest to people involved
in providing data communication links between a remote location
and a central site, and remote offices to each other. The data communication 
can be ascii text files; images and other binary files, or as simple as e-mail.
The reports discuss:
 A: Remote bridging and routing: wide area networking considerations
    Author is Mike Drollman, manager :sales engineering. The 
    40 page report provides an overview of the comparison between
    bridging vs routing and some specific application and
    engineering considerations for each alternative. Specifics
    of various protocols are itemized and problems unique to
    each of the prevailing WAN protocols are discussed (TCP/IP)
    IPX, LAT, SNA, etc). The paper is primarily discussing 
    ethernet LANS but most of the application information
    also applies to token ring.
B:  General Description of Dial-up Internetworking:
    This is copies of a slide presention used at seminars
    to give a graphical description of Internetworking
    functions as it applies to Dial-Up Data communications
    over a WAN. 

 C: Technical brochures are available on the 
    BREEZE 1000 a integrated dial-up bridge/router with modem (v.32bis or vfast)
    BREEZE 1100 a bridge/router for RS-232 to CSU,Frame relay, SW56, etc.
    BREEZE 2000 a bridge/router 2ports with sync or async on either port, Integrated WAN modules  csu-dsu; isdn;modems,frads are available

   Anyone interested in any or all of this information can reach me at
jahansen@networksnw.com
or
1-206-641-8779  tel
1-206-641-8909  fax
1-800-835-9462  tel

or see us at interop :booth 6370

or smail
John A Hansen
Director Sales
Networks Northwest Inc.
PO Box 40209
Bellevue Wa 98015







-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 12:29:50 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: Port TCP/IP apps to X.25

In article <wchenCuC4oM.CFA@netcom.com> wchen@netcom.com (Wen Chen) writes:
>Hi,
>
>We have developed our distributed application for TCP/IP protocol.  Now, 
>we need to port our code to X.25.  Our goal is to keep the change to our
>code minimum it at all.

  The simplest method would be to just run tcp/ip on top of X.25.

  Otherwise you will rapidly discover the difference between a REAL
  socket type interface of tcp/ip with the protocol protection and
  the underlying layers compared to a hack from a nameless vendor
  who put a socket interface right on top of X.25--which is nothing
  but a glorified link layer.   

>
>For those who are familiar with the protocol stack, do you think if we 
>can approach it by pushing a TCP stream module on top of the X.25 
>driver/module.  We are relatively new to this territory.  Any suggestions 
>are appreciated. 

  Its a bit more complicated than that, but not rocket science.  If
  your X.25 must traverse public packet networks, you will need a
  "miracle" layer which puts your tcp stuff in and out of packets as
  well as magic to map X.121 addresses, X.25 parameters, X.25
  facilities, call request handling etc.   If this is a private
  network you may be able to do what milnet does and use an algorithm
  to map the internet address to the X.25 dte address.  

  Of course if your application is pretty much tty semantics it should
  be no big deal running it on X.25/X.29.  

  If you choose to go with tcp/ip on X.25 you may want to get not only
  the RFC but also the old 'CSNET' white papers if you intend to
  implement the stack yourselves...otherwise the simplest thing is to
  contact your vendor(s) and see if they have the option to run tcp/ip
  on X.25.   



-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 94 00:58:27 GMT
From:      marco@dmrt-2.dmrt.nl
To:        comp.protocols.tcp-ip
Subject:   Re: Routing & subnetting on a Novell Server

sej@psycfrnd.interaccess.com (Stephen Johnson) writes:

>I have not had good luck running Novell servers as routers with
>different subnet masks on different interfaces. Might be my problem,
>might not :)

No, it's not your problem :-). Only the latest TCPIP.NLM (TCP187.EXE on 
ftp.novell.com) adds implicit support for this.
                                               
			Marco.
--

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 01:18:30 GMT
From:      schan@gcau.com.au (Stanley Chan)
To:        comp.protocols.tcp-ip
Subject:   Re: Which application uses UDP port 16000?

Goh Cheng-Seng (csgoh@iti.gov.sg) wrote:
: We experienced a serious broadcast storm this afternoon which, according
: to our Sniffer, is caused a workstation (in anohter subnet that is not
: under our control) that is continuously sending to the IP address
: 255.255.255.255. Both the source and destination port numbers are
: identified to be UDP port 16000.
 
: Does any of you know of any PD applications that uses that port?

Could be some one who wrote a program to do it. 

--
Stanley Chan				(System Administrator)
E-mail schan@gcau.com.au 		(Ph 61-7-8771016 Fax 61-7-8771120)
Snail  Golden Casket Art Union Office
       Locked Bag 7, Coorparoo DC QLD Australia 4151



-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 01:29:51 GMT
From:      schan@gcau.com.au (Stanley Chan)
To:        comp.protocols.tcp-ip
Subject:   Re: help please-daemon process on UNIX

Lance Lu (al395@FreeNet.Carleton.CA) wrote:



: I am going to write an application which will run as a daemon process.
: I want to know what difference from normal process in terms of coding.
 
: Do I need to disassociate from process group or ignore terminal I/O signals?
 
: If yes, how to capture kill signals?
 
: Any advice is appreciated.
There are three things you have to do when writing a daemon.

1) The program should fork off a child and the child then goes into
 endless loop. This is your daemon process. Then the parent should exit.
2) Set the group of the child  to previelge group after started. There is
a special command in HPUX to do it I think it is setprevgrp or something
like that. This will put
the deamon program as parent of any child process and disassociate itself 
from the tty.
3) The program should be setuid and own by root if you want it to do 
some system functions, this is what a daemon is for generally.
 You can do this inside the program.

You should be able to kill it as root if you have not ignore all 
signals.
--
Stanley Chan				(System Administrator)
E-mail schan@gcau.com.au 		(Ph 61-7-8771016 Fax 61-7-8771120)
Snail  Golden Casket Art Union Office
       Locked Bag 7, Coorparoo DC QLD Australia 4151



-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 94 02:49:23 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: setsockopt not working in TCP/IP for OS2

In article <4aZIkmoZjmY0069yn@msen.com>, brain@msen.com (Jim Brain) writes:
| This is a pretty narrow question, so I don't know if this is the place, but...
| 
| In TCP/IP for OS/2, I want to start multiple server apps listening on the
| same address/port.  Note that each server is a separate executable.

Ok, first of all you haven't said which tcp/ip for OS/2.  There are
now a number...  Second, it isn't completely clear what you want to do.
Do you want an incoming connection request for a particular port to
be picked up by one of many servers at random?  I don't think you can
get this behavior in the way you describe.

| I thought I could have each executible do 
| setsockopt(s,SOL_SOCKET,SO_REUSEADDR,...), but I am unsure of how to do this.

In general, SO_REUSEADDR is used by servers that may be restarted while
existing connections using their well-known local port persist.  The
normal rules prevent a socket from binding to a local port if that local
port is in use by any connection.  SO_REUSEADDR relaxes this restriction
by allowing a bind to a local port/address which is in use, provided the
remote port/address does not also match.

Actually, while the above is a textbook description of SO_REUSEADDR, the
implementation is usually a bit different.  SO_REUSEADDR typically simply
disables wildcard matching in a protocol control block lookup routine.
Since the foreign address is not set at the time you call bind, and since
you are usually trying to bind to the local wildcard address, the effect
is as described.  (You could bind multiple unconnected sockets to the same
local port without SO_REUSEADDR so long as each socket used a unique local
IP address.  But this is getting obscure.)  However, even under SO_REUSEADDR
rules, a wildcard still matches another wildcard.  So you should not be able
to bind two sockets to the local wildcard address for the same port.  And
it sounds as if that's what you want.

| So, trying to experiment, I did:
| 
| Server prg
| 
| socket;
| setsockopt(s,SOL_SOCKET,SO_REUSEADDR,temp,1);
| 
| where temp is char * with a decimal 1 in it.

In this example, the fourth argument should be a pointer to a variable
containing a 1.  By tradition, this variable is an int (but see below),
so you want something like:

int temp = 1;

setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (char *)&temp, sizeof(temp));

| rc for this give -1, errno gives 10022, which is invalid argument.

This value for errno suggests that you are using IBM's tcp/ip product
with C/Set 2.  That opens up several possibilities.  See below.

| Am I missing something?

No doubt. :)

|Has anyone tried to use setsockopt on OS/2?

All the time, but not with IBM's tcp/ip...

| Note that temp was originally an int casted to (char *), and length was 2, 
| but I have tried a bunch of mutations since then.

Ok, as I mentioned, the argument pointed to for the SO_REUSEADDR option
is traditionally an int.  By further tradition, the code merely checks that
the passed size is >= sizeof(int).  Now, I don't know whether the driver
code in question is still 16-bit or for that matter whether the 32-bit
C/Set 2-compatible library makes a separate check.  In any case, EINVAL
is the error returned by the standard BSD code when the passed length is
too small.  I would suggest that you try the native int size for the compiler
you are using (as shown above).  If that fails, try short on the theory that
they may be checking == sizeof(int) in a 16-bit driver.

It may be the case that some level of library or driver code recognized
your temp address as bogus and returned EINVAL rather than the more
conventional EFAULT.  If this was the problem, then the above example
should work without further changes.  (By work, I mean not return an
error.  It still won't solve the problem presented. :)

				Dan Lanciani
				ddl@harvard.*

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 94 10:08:03 PDT
From:      todd.myhre@medtronic.com
To:        comp.protocols.tcp-ip
Cc:        mhyman@netcom.com
Subject:   Re: Sun <-> AS/400



> 
> Has anyone had any experience with connecting Sun SPARC systems
> running Solaris 2.3(+patches) to an AS/400 running their (IBM's)
> TCP/IP implementation.
> 
> We might be doing just this and I am looking for any input
> in the following areas:
> 
> 1. Standard TCP utilities like rcp, ping, etc. Do they work the same?

AS/400 TCP/IP is very weak as far as r commands.  What you will basically get 
is good FTP and Telnet.  One warning, if your AS/400 is V2R3 or earlier, you 
are limeted to 160 buffers.  This means that you are limited to the number of 
telnet and ftp users on the AS/400.  Each telnet session takes 2 buffers and 
ftp can take up to 4 buffers.  You will run into problems if you get close to 
the buffer limit.  16MB is the max file size for a FTP transfer.

> 
> 2. NIS/NIS+ do these exist on the AS/400 and can the AS/400 be
> part of a specific domain, with a master server onSolaris?

yes, yes

> 
> 3. How does NFS perform, we are looking at transferring up to
> 2GB of data nightly with NFS, am I crazy??

separate product and it is not that great.

> 
> 4. EBCDIC to ASCII issues. When doing file transfers are the file
> contents translated properly.

no

> 
> 5. E-Mail. Does the AS/400 handle SMPT e-mail at all??
> 

very weak, but can be done using OfficeVision/400.

> 6. FDDI. We will be connecting the Sun and AS/400 together over
> FDDI, is this too new to work properly, again any issues??
> 

no, there shouldn't be.

> Thanks in advance for any and all information. I will post 
> a summary of responses once I get them.
> 
> ....Mike Hyman
> 
> Please respond to: mhyman@netcom.com


-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 15:33:31 -0700
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   Re: How many DNS servers do we need?

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

>One simple bit of guidance on name servers please...
much deleted...

>How many DNS servers do we need, in principle?  One per site? One
>per Division? Shared between Departments?  Does it matter?

Technically, you only need one.  If you are connecting to the Internet,
you'll probably have to have two (primary and secondary).  You can
set up as many as you want, tho the zone transfers between a bunch
of secondary's and the primary can get expensive (bandwidth wise).
If it was me, I would set up a primary and a single secondary, both
'well connected', and widely separated.  Then I would set up a bunch
of slave 'caching' name servers.  One book you did not mention reading
was DNS/BIND published by O'reilly and Assoc.  That one is my
bible.
-- 
    /|                          Tom Brink
 \`o.0'                         tbrink@crl.com
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 11:31:11 -0400
From:      manmetha@gauss.rutgers.edu (Rajesh Malhotra)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   What prog to use to download news on an IBM RS6000, AIX 3.2.5?


Fellow Nett'ers,

	What programs could I use to download news, and for news reading
on an IBM RS6000? The reader should preferably be X based AND ascii based.

	Any and all help on this matter appreciated.

Thanx,

Raj.



-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 94 10:12:42
From:      kstailey@leidecker.std.com (Kenneth Stailey)
To:        comp.protocols.tcp-ip,comp.unix.programmer,comp.sys.ncr
Subject:   Re: Binding a DGRAM (UDP) socket?


>I am having a problem with UDP sockets in the context of broacast addrs.
>I am implementing a dynamic BOOTP server, and one of the problems I 
>need to solve is "Which interface did the bootp request come in on?"
>
>In our environment, bootp is being used to assign the IP addr, and as
>such, the client is setting the source IP address to INADDR_ANY(0.0.0.0).
>It is also setting the destination addr to broadcast, as it has no
>knowledge of who the bootp server might be.
>
>When the request comes to the server, if the server is listening on 
>a socket bound to INADDR_ANY, it hears the request just fine.  However,
>if I listen on a set of sockets, each bound to the addr of one of the
>interfaces, I never see the requests.
>
>Is there some way to determine which interface the datagram came in on?

Are you doing an accept() after the listen()?
Doesn't accept() return the remote address?

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 94 10:23:22
From:      kstailey@leidecker.std.com (Kenneth Stailey)
To:        comp.protocols.tcp-ip
Subject:   ICMP "destination unreachable" error question

I know that ICMP "destination unreachable" (specifically port
unreachable) errors are generated in response to receiving UDP packets
(other than broadcast packets) addressed to ports that have no listens
posted.

My question is on UN*X systems (esp. HP-UX) does anything else cause
an ICMP destination unreachable error?

Searching through 4.3BSD sources, I only found calls to icmp_error()
in udp_usrreq().

Thanks,
Ken

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 06:06:45 GMT
From:      hofmann@netz.hrz.uni-siegen.de (Lothar Hofmann)
To:        comp.protocols.tcp-ip
Subject:   Microsoft Wolferine

Hi,

is there any ftp-server to get microsoft wolverine tcp/ip software from?

Thanks for help

Lothar Hofmann

-----
Lothar Hofmann  HRZ / computer center		Mail: hofmann@hrz.uni-siegen.de
Universitaet-GH-Siegen
Hoelderlinstr. 3				Phone: +49 271 740 4760
D - 57068 Siegen				Fax:   +49 271 740 2523



-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 12:01:47
From:      tnemeth@immuno.imvs.sa.gov.au (Tom Nemeth)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PCs as IP routers

In article <1994Aug03.181529.24484@cse.iitb.ernet.in> vinod@cse.iitb.ernet.in (Vinod G Kulkarni) writes:

>: Philip Burton (philip.burton@spacebbs.com) wrote:
>: : Does anyone have experience with PC-based TCP/IP packages that can do IP 
>: : routing?  under DOS?  under Windows?  
 
>One solution is to use Linux as router. (And running gated if required.)
>However, it still doesn't have IPX routing.

This is obviously one of the MAIN reasons to do it this way!  Unless you are 
already routing IPX, you probably DON'T want to do it... there are much more 
subtle (and probably far less expensive) ways to achieve what you think you 
are trying to do.

> ... The 386 can also act as 
>NFS server etc., so it is quite good if needs are limited (and saves you
>a PC which would otherwise be dedicated to routing.).

Well, only if you believe that routers should be allowed to do other things.  
Yes, it is possible, but IMHO far from desirable.  This is also why I do not 
allow Novell file servers to be set up as routers: servers should serve, and 
routers should route, period.  PC-Router works fine, maybe you should look at 
that for an IP-only router; policy-wise it is simple and makes network 
management much easier (not to mention traffic).

Tom Nemeth


-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 08:02:29 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   How many DNS servers do we need?

One simple bit of guidance on name servers please...

I am advising on the setting up of a very big IP network (50/60 sites)
varying from 2/3 PCs to several hundred PCs and several hosts. (They
have no TCP/IP except a couple of isolated pockets).

I want to work out how best to structure the names under the root
domain of "this_org.co.uk"

We have a hierarchy of Divisions, Departments and Sections.  These
are scattered all over the territory (eg. a very small office might
have one person from each Division, and a very big site might be 
100% staffed by a specific department of a Division).

How many DNS servers do we need, in principle?  One per site? One
per Division? Shared between Departments?  Does it matter?

Is the structure/deployment of DNS servers dependent on whether 
we have a "two-level" name or a "three-level" name below the root?

I.e., if we choose host names as: "host.section.dept.div.this_org.co.uk"

do we need to configure **more** DNS servers that if we chose:

				 "host.dept.div.this_org.co.uk"

I have read all the books I can find: Comer, Stevens, Santifaller,
Washburn & Evans, Carig Hunt....  they are very good and explain 
very clearly how bind & DNS and in_arpa.addr works.... but they
leave me uncertain on how to set up a structure.

TIA,  Phil

-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 13:06:29
From:      padgett@141.240.2.145 (Padgett 0sirius)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp shareware

In article <32e49l$5gv@tibalt.supernet.ab.ca> dbform@tibalt.supernet.ab.ca (Data Business Forms) writes:
(see title)
The packet drivers distributed by Crynwr and FTP, PING, etc in the 
WATTCP package from the University of Waterloo (.CA) are a good start. Add 
NCSA Telnet and you have a basic service for the PC. Kermit (v3.13 is 
current) also has Telnet capability but the NCSA product is easier to use.

From there (e.g. to get traceroute, nicname, or smtp capability) IMHO the 
best choice if you do not want to "roll your own" is the FTP PCTCP software 
commercial offering.

A FAQ question maybe ?

			A. Padgett Peterson, P.E.
                        Cybernetic Psychophysicist
			   We also walk dogs
	 	       PGP 2.4 Public Key Available

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 08:19:40 GMT
From:      simmons@EE.MsState.Edu (David Simmons)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PCs as IP routers

In article <tnemeth.69.000C0802@immuno.imvs.sa.gov.au>,
Tom Nemeth <tnemeth@immuno.imvs.sa.gov.au> wrote:
>In article <1994Aug03.181529.24484@cse.iitb.ernet.in> vinod@cse.iitb.ernet.in (Vinod G Kulkarni) writes:
>
>>: Philip Burton (philip.burton@spacebbs.com) wrote:
>>: : Does anyone have experience with PC-based TCP/IP packages that can do IP 
>>: : routing?  under DOS?  under Windows?  
 
>>One solution is to use Linux as router. (And running gated if required.)
>>However, it still doesn't have IPX routing.
>
>This is obviously one of the MAIN reasons to do it this way!  Unless you are 
>already routing IPX, you probably DON'T want to do it... there are much more 
>subtle (and probably far less expensive) ways to achieve what you think you 
>are trying to do.

I've heard that you can't beat a 286 for routing, if it is the ONLY thing it
is doing.  I think the KA9Q software will handle that.
(save your 386 with Linux for NFS, terminals, etc. :)

David

-- 
David Simmons, System Administrator                 simmons@ee.msstate.edu
Mississippi State University Electrical and Computer Engineering
Visit my home page!  http://www.ee.msstate.edu/~simmons

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 17:04:06 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip
Subject:   PD source for inetd anyone?

This probably belongs in a *N*X group, but it does realte to tcp/ip/
the inetd superserver performs the TCP/IP program starting function for
TCP/IP.  Therfore, I would like to know if a PD version of it exists I can 
hack up to see how such a server works.


--		       
Jim Brain, Embedded Systems Designer, Brain Innovations.
brain@msen.com  
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain


-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 14:13:59 GMT
From:      teffta@erie.ge.com (Andrew R. Tefft)
To:        comp.protocols.tcp-ip
Subject:   Re: Multi-user PPP?

In article pdr@hermes.louisville.edu, ewtayl01@starbase.spd.louisville.edu (Eric W. Taylor) writes:
>The easiest way I know to do what you described would be to run Linux on
>the PC that is going to use the ppp connection.  Linux will require about
>4-5 megs of ram, 90-100 megs of hard drive space.


No, no. I just set up a demo linux installation on a laptop, inside the
existing dos partition, in < 15 megs. Adding ppp ability to that would
not take significantly more space. This is not too bad when Linux will
only be run occasionally; it can still remain a dos box. No need to
install *everything* and convert to full-time Linux!

---

Andy Tefft               - new, expanded .sig -     teffta@erie.ge.com



-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 15:35:52 GMT
From:      rcreager@sadira.gb.nrao.edu (Ramon E. Creager)
To:        comp.protocols.tcp-ip
Subject:   talk and ntalk protocols: where defined?

Would someone kindly (via e-mail) point me to where these protocols are 
defined?  I can't find any RFC that does so.

Thanks, 

  Ray Creager
  rcreager@sadira.gb.nrao.edu

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 16:30:04 GMT
From:      bhaskar@brtph181.bnr.ca (Shaji Bhaskar)
To:        comp.protocols.tcp-ip
Subject:   Vendors for kernel-independent TCP/IP?


Hi,

We are looking for TCP/IP vendors for an embedded system.
Our requirements are:
1. Must run on our proprietary multitasking kernel.
2. Must run on 680X0 processors.
3. Must have a network interface that is configurable for our proprietary
   system.
Streams would be very nice to have.

I'd appreciate help locating vendors of such a beast.  Also, I'd like
to hear from people with good/bad experiences about specific products.

Thanks much,

Shaji Bhaskar
-- 
----------------------------------------------------------------------------
Shaji Bhaskar                                             bhaskar@bnr.ca
BNR, Research Triangle Park, NC 27709, USA                (919) 991 7125

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 17:06:27 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: does "routed" support split horizon/poison reverse/triggered updates

>>> On Thu, 11 Aug 1994 14:53:10 GMT, vjs@calcite.rhyolite.com (Vernon
>>> Schryver) said:

Vernon> In article <CuC50p.1Cu8@austin.ibm.com> ramana@austin.ibm.com
Vernon> (Anand Teerth Desai) writes:

Anand> Does anyone know if BSD4.3/BSD4.4 versions of "routed" command
Anand> (routing protocol daemon) support Split Horizon / Poison Reverse
Anand> or triggered updates ? 

Vernon> 4.3BSD-reno does all three.  Check the source at your nearest
Vernon> repository or CDROM.

Another good idea :-) is to use gated even when routed would suffice.
Build in future proofing -- better to have gated already in place...

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 18:16:00 GMT
From:      dscially@interserv.com
To:        comp.protocols.tcp-ip
Subject:   Re: Tech Report Available

Is your tech report available for a price or is it the graciousness of your generosity that you'll provide it for free?  If it's free then post it somewhere for us to read it at our leisure.  If there is a fee, then, in my humble opinion, pay to advertise your services over the appropriate mediums.

No malice intended.

David

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 18:25:03 GMT
From:      woan@exeter.austin.ibm.com (Ronald S. Woan)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Re: What prog to use to download news on an IBM RS6000, AIX 3.2.5?

In article <32g4jv$3m5@gauss.rutgers.edu>,
Rajesh Malhotra <manmetha@gauss.rutgers.edu> wrote:
>	What programs could I use to download news, and for news reading
>on an IBM RS6000? The reader should preferably be X based AND ascii based.

The same as with other UNIX systems (trn, tin, tass, strn, gnus, xrn,
etc...). news.software.readers is a good place to learn about these.
-- 
+------All Views Expressed Are My Own And Not Necessarily Shared By IBM-----+
+ Ronald S. Woan       (IBM VNET)WOAN AT AUSTIN, woan@exeter.austin.ibm.com +
+ outside of IBM  woan@austin.ibm.com or woan@cactus.org or r.woan@ieee.org +
+ others     woan@soda.berkeley.edu Prodigy: XTCR74A Compuserve: 73530,2537 +

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Aug 1994 15:07:06 +0200
From:      grandjen@georges.montefiore.ulg.ac.be (Grandjean Vincent)
To:        comp.protocols.tcp-ip
Subject:   traffic generator

Hello,

I'm looking for articles or other information on traffic simulation (model).
I'm looking for examples of :
	- times between UDP datagrams,
	- times between TCP segments,
	- size of TCP windows,
	- size of UDP datagrams,
	- size of TCP segment,
	- ...
in FTP, RLOGIN, TELNEL applications

Thank you for any help,

-Grandjean Vincent, e-mail grandjen@montefiore.ulg.ac.be


-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 19:23:34 GMT
From:      mre@teal.eng.sun.com (Mike Eisler)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Cc:        
Subject:   Re: reliable broadcast protocol sought

In article <mac.776592521@hawk>, Mark Cook <mac@adied.oz.au> wrote:
>Seeking software which provides reliable (guaranteed) broadcast delivery
>over Ethernet/FDDI LAN.
>
>Regards, Mark

No software, but an algorithm. Read the paper:

       AN EFFICIENT RELIABLE BROADCAST PROTOCOL
		by
       M. Frans Kaashoek
       Andrew S. Tanenbaum
       Susan Flynn Hummel
       Henri E. Bal
		of
       Vrije Universiteit
       Amsterdam, The Netherlands

This and other Amoeba papers are supposed to be available under
ftp.cs.vu.nl:/pub/amoeba/amoeba_papers
-- 
	-Mike Eisler
	mre@Eng.Sun.Com

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      12 Aug 1994 23:06:22 GMT
From:      jj@insane.apana.org.au (J.J. Pantebre)
To:        comp.protocols.tcp-ip
Subject:   Re: Microsoft Wolferine

In article <32f3hl$6vi@si-nic.hrz.uni-siegen.de>, hofmann@netz.hrz.uni-siegen.de (Lothar Hofmann) says:
>
>Hi,
>
>is there any ftp-server to get microsoft wolverine tcp/ip software from?
>

yes - try ftp.microsoft.com for beta-3 release. works well but I am still looking for
a slip or ppp driver that works with it's winsock. Please let me know if you find one.

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Aug 1994 00:18:03 GMT
From:      pjh@pjh.jvnc.net (Pete Holsberg)
To:        comp.protocols.tcp-ip
Subject:   RARP vs. BOOTP

(I hope that this is the correct newsgroup.)

Could someone explain what the difference between RARP and BOOTP is, from the 
standpoint of dynamic IP addressing?

Thanks.

------------------------------------------------------------------
Pete Holsberg                   The House On *This* Side Of U.S. 1
44 Lopatcong Drive              pjh@mccc.edu
Ewing, NJ 08638                 pjh@pjh.jvnc.net
FAX: 609-586-2318
------------------------------------------------------------------
    **** Trenton Computer Festival **** April 22-23, 1995 ****
------------------------------------------------------------------

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1994 03:32:09 GMT
From:      paf@staff.nada.kth.se (Patrik Faltstrom)
To:        comp.protocols.tcp-ip,comp.infosystems
Subject:   Re: What ever happened to whois++?

In article <32d688$dsl@zeus.swindon.rtsg.mot.com> jasonh@chineham.euro.csg.mot.com (Jason Haar) writes:
>Says it all really. Is whois++ still been developed, or has X.500 won the 
>day in the White Pages (-type) front?

Whois++ is still under development. The first couple of RFC's
will be out any day now. You can look at the "golden master"
internet drafts under the name "draft-wnils-*" at your favourite
internet-drafts directory, for example nic.nordu.net.

What is happening is that we are working on a world-wide pilot
project which will be up an running during october. Today we
are running Whois++ for white-pages services on the Swedish
University Network, and this first test involves 3 universities
and about 10 departments which have one Whois++ server each.

What implementions have I heard of so far:

- Richard Schoultz do have one client and one server written
  in perl which uses dbm as database. You can get this
  from, I think, anonymous ftp from sunic.sunet.se in the
  directory whois++ (or something like that).

- Richard is currently rewriting his server in C++.

- I am writing a Whois++ server whish uses an existing
  SQL database in the bottom by using embedded SQL.
  It is running today, but it will not be released
  even to alpha-testers earlier than november 1994.

There is also three other implementations on it's way which
will be used during this first pilot we will run this fall.

One other very interesting implementation is one Michael Mealling have
written. It's an URN -> URL resolver package to NCSA Mosaic which uses
Whois++ for the actual job. I.e. you write an URN in the HTML
code, Mosaic will query for one or more URL's which will be presented
as a clickable document (or directly resolved if there was only
one match).

So, I think Whois++ is really getting implemented now.

	Patrik

P.S. Note that I am not a reader of any of these newsgroups. I got
     this message from a friend of mine and thought I should
     inform you what is happening. More comments to me
     by email, please.

==============================================================================
Patrik Fältström                        Internet: paf@nada.kth.se
Department of Numerical Analysis        BITNET:   paf@sekth
  and Computing Science                 Phone: +46-8-7906274
Royal Institute of Technology           Fax:   +46-8-7900930
S-100 44 Stockholm
Sweden
                      

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Aug 1994 05:32:35 GMT
From:      jsjensen@slate.mines.colorado.edu (JS Jensen)
To:        comp.dcom.modems,comp.dcom.servers,comp.protocols.ppp,comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Multi-user PPP?


Hmmmm...

There is a program called ETHERPPP which connects PPP through DOS.  I 
would then use a program called DOORWAY which redirects cursor based 
programs through serial ports.  Yes there is more...get the telnet client 
program from NCSA, ftp is ncsa.uiuc.edu, I think they still have 
everything there.  The tricky part is you will have to 
connect under a multi-tasking environment.  Suggestion, get an old copy 
of Desqview, or hope nothing goes wrong under Windoze.

I can probably find ETHERPPP and DOORWAY, if you want, mail me and
I'll see what I can do.

jsjensen@mines.colorado.edu
Tumbleweed Media
J.S. Jensen

-- 
[ jsjensen@Mines.Colorado.EDU ]

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 94 05:51:05 GMT
From:      larkinrp@cs.curtin.edu.au (Richard Larkin)
To:        comp.protocols.tcp-ip
Subject:   RPC (Remote Procedure Call) Request for information

I would like to know if anyone has any good sites/examples/tutorials on
programming with RPC. It is for an assignment in my course and I am too
stingy to buy the RPC book (O'reilly and associates) and was wondering if
there are any good information sites available that you guys know of.

Much help appreciated in advance thanking you.


Richard Larkin
Honours Student
Computer Science@Curtin University of Technology
Kent Street, Bentley  6102
Perth, Western Australia

--
Richard Larkin
Honours Student
Computer Science@Curtin University of Technology
Kent Street, Bentley  6102
Perth, Western Australia


-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1994 14:27:34 -0400
From:      wenhui@news.cs.columbia.edu (Wen-Hui Luo)
To:        comp.protocols.tcp-ip
Subject:   boardcast on multiple interfaces.

Hi,

I have a situation which requires a machine with 2 interfaces able to
send and receive boardcast packets using 255.255.255.255 and
meanwhile, able to tell which interface where the packet comes from.
Natually, I created two sockets, one for each interface and 
with its own IP address binded to each socket.  However, what happens
is that no boardcasted packet is able to come in from the interface
throuth the socket. Depending on which tcpip kernel you are using,
sometimes it doesn't boardcast using the socket binded to a specific
IP address and using 255.255.255.255 as the out going IP address.

Is there any reason why this happens and what could be the solution?
Thank you.

Kevin.


-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1994 17:59:23 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.dcom.servers,comp.answers,news.answers
Subject:   comp.dcom.sys.cisco Frequently Asked Questions (FAQ) [draft THREE]

Archive-name: cisco-networking-faq
Last-modified: 27 July 1994
Version: Beta 0.3

This is the DRAFT frequently asked questions (FAQ) list for
comp.dcom.sys.cisco. Once it leaves draft form, this FAQ will be
posted twice monthly; prior to that it will be posted more-often until
we get it right. :-)

There should evntually be an html version of this FAQ
available. Question should also be numbered, and perhaps divided into
subcategories for large things (like ntp...); also, they need to be
sorted.

Please contribute answers to the questions in the Todo section! If your
answer is somewhat complicated, posting would probably be best (to
comp.dcom.sys.cisco). Otherwise, e-mail it to cisco-faq@panix.com. I
meant to get some of these todos done, but I've just been too busy, so
I'm posting this as-is now. 

This draft FAQ is in RFC1153 digest format, so you can follow each
question with your newsreader. I suppose that question-numbers should
be moved to the From: field. Note that Date: fields represent
last-modification times for the questions.

Table of Contents
=================

1.	How can I contact cisco?
2.	What is this newsgroup?
3.	What's the first letter in ``cisco''?
4.	How do I save the configuration of a cisco?
5.	Where can I get ancillary software for my cisco?
6.	Is there a World-Wide-Web (www) information source?
7.	How can I get my cisco to talk to a third party router over 
8.	How can I get my cisco to talk to a 3rd-party router over Frame Relay?
9.	How can I use debugging?
10.	How can I use NTP (Network Time Protocol) with my cisco?
10a.    Sample NTP configurations
11.	Presence of cisco employees here
12.	How do I avoid the annoying DNS lookup if I have misspelled a command?
13.	Tracing bad routing information
14.	Acknowledgements.

todo:
=====

* How to configure TACACS
* What is SNMP and how can I use it? What software is available and how do
I use Cisco enterprise MIBs?
  MIBs on ftp.cisco.com and CIO.cisco.com
* Pointers to other s/w that's particularly useful in this sort
of routing environment (like Charley Kline's VLSM program).
* Sample configurations of complicated things, like NTP. Also
routing protocols samples, but care should be taken not to just
duplicate the docs.
* Pointers to other net resources, like comp.protocols.tcp-ip, RFCs,
the firewalls mailing list, etc (bgpd?[or is it cidrd now? :-)]).
* Hints about confusing and not-well documented things like xtacacs...
* Comments on interoperability issues WRT other vendors.
* What's SMARTnet, why should I subscribe, how much does it cost,
and what do I get?
* What should I name my router, my interfaces, etc.?
* How should I restrict access to my router?
* What can I do about source routing?
* Where can I buy Cisco equipment.
	mail order
	used
	turnkey
		(much hand-holding/pre-setup)
	etc?
*  Should we adjust the buffer parameters on the routers?  What should be the 
   indicator before tunning the buffer parameters?  How should one fine tune the
   buffer parapeters?
*  discribtions of "show buffer" output, how should one read these output?
*  what routing protocol should I use?
*  what is the real purpose of the network subcommand of
   router commands?  When do I not want to include a network
   I know about?
*  What is a VLSM and why would I want one?  What supports
   them?
*  What is CIDR and why do I care (or a more general acronym decoder) ?
*  How do I configure my Cisco to use variable-length subnetting ?
*  What are some methods for conserving IP addresses for
   serial lines?
*  Is there a block of private network numbers I can use
   within my organization only?  When should I use them?
   How do I access them from outside?
*  What do I do if I have to partition a network number?
*  Questions and answers about access lists
   access-list reference list (lots of questions on that)
*  I forgot to mention that routing DECnet over X.25 is a problem.
*  Where PD network applications for SLIP/PPP are.
*  What is HSRP and how does it work?  When is it available (10.0) (Hot Standby Routing Protocol)
*  The whole 1597/1627 debate. This needs to be handled
   CAREFULLY!

The Real Stuff:
===============

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

From: cisco-faq
Date: 27 July 1994
Subject: How can I contact cisco?

The following phone numbers are available:

  Technical Assistance Center (TAC)                     +1 800 553 6387
                                                        +1 800 553 2447
                                                              (553 24HR)
							+1 415 903 7208
  TAC FAX						+1 415 903 8787
  Training Services                                     +1 415 903 7290
[
  Protocol Interface (cisco Systems Training Partner)   +1 415 491 8950

It has been suggested that this is not a cisco number. Can someone
confirm this?

]

  Customer Service (Documentation, Warranty &           +1 800 553 6387
      Contract Services, Order Status
  Order Processing                                      +1 415 903 7231
  Engineering                                           +1 800 553 2447
                                                              (553 NETS)
  On-site Services, Time & Materials Service            +1 800 829 2447
                                                              (829 NETS)
  Main number / general					+1 408 526 4000
  Main FAX (NOT tech support)				+1 408 526 4100

[ Wait a second -- NETS and 24HR cannot expand to the same thing! PR sez
NETS is preferred... ]

All of the above 415 area code numbers will be changing soon (around
August), when cisco completes its move to San Jose (from Menlo Park),
California.

cisco can also be contacted via e-mail:

	tac@cisco.com 		Technical Assistance Center
	tac-euro@cisco.com	European TAC
	cs-rep@cisco.com	Literature and administrative (?) requests
	cs@cisco.com		*UNRELIABLE*, special-interest, "non-support"

Please follow the directions available on CIO before doing this.
cisco provides an on-line service for information about their routers
and other products, called CIO (cisco Information Online).  telnet to
cio.cisco.com for more details.

The collective experience of this FAQ indicates that it is far wiser to
open a case using e-mail than FAXes, which may be mislaid, shredded,
etc.

For those of you still in the paperfull office (unlike the rest of us),
cisco Systems' new corporate address is:

	170 West Tasman Drive
	San Jose, CA 95134


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

From: cisco-faq
Date: 26 July 1994
Subject: What is this newsgroup?

comp.dcom.sys.cisco, which is gatewayed to the mailing list
cisco@spot.colorado.edu, is a newsgroup for discussion of cisco
hardware, software, and related issues. Remember that you can also
consult with cisco technical support.

This newsgroup is not an official cisco support channel, and should
not be relied upon for answers, particularly answers from cisco
Systems employees.

Until recently, the mailing list was gatewayed into the newsgroup,
one-way. It is possible that this arrangement may resume at somet time
in the future.

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

From: cisco-faq
Date: 26 July 1994
Subject: What does cisco stand for?

cisco folklore time:

At one point in time, the first letter in cisco Systems was a
lowercase ``c''. At present, various factions within the company have
adopted a capital ``C'', while fierce traditionalists (as well as some
others) continue to use the lowercase variant.

cisco is not C.I.S.C.O. but is short for San Francisco, so the story
goes.  Back in the early days when the founders Len Bosack and Sandy
Lerner and appropriate legal entities were trying to come up with a name
they did many searches for non similar names, and always came up with a
name which was denied. Eventually someone suggested "cisco" and the name
wasn't taken (although SYSCO may be confusingly similar sounding). There
was an East Coast company which later was using the "CISCO" name (I
think they sold in the IBM marketplace) they ended up having to not use
the CISCO abberviation.  Today many people spell cisco with a capital
"C", citing problems in getting the lowercase "c" right in publications,
etc. This lead to at least one amusing article headlined "Cisco grows
up". This winter we will celebrate our 10th year.

[This text was written in July of 1994 -ed]

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

From: cisco-faq
Date: 5 July 1994
Subject: How do I save the configuration of a cisco?

If you have a tftp server available, you can create a file on the
server for your router to write to, and then use the write network
command:

	mytftpserver$ touch /var/spool/tftpboot/myconfig
	mytftpserver$ chmod a+w /var/spool/tftpboot/myconfig

	myrouter#write net
	Remote host [10.7.0.63]? 10.7.0.2
	Name of configuration file to write [myrouter-confg]? foobar
	Write file foobar on host 10.7.0.2? [confirm] y

Additionally, you can also use expect, available from:

	ftp://ftp.uu.net/languages/tcl/expect/expect.tar.gz
	ftp://ftp.cme.nist.gov/expect/expect.tar.gz

or, in shar form from ftp.cisco.com.

Expect allows you to write a script which telnets to the router and
performs a ``write terminal'' command, or any other arbitrary set of
command(s), using a structured scripting language (Tcl).

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

From: cisco-faq
Date: 5 July 1994
Subject: Where can I get ancillary software for my cisco?

Try ftping to

	ftp://ftp.cisco.com/pub

It's a hodgepodge collection of useful stuff, some maintained and some
not. Some is also available from

	ftp://cio.cisco.com

Vikas Aggarwal has a very customised tacacsd:

A new version of xtacacsd is available via anonymous FTP from
'ftp.navya.com' (128.121.50.145)  under pub/vikas/xtacacsd.shar.
This version should also be available from ftp.cisco.com soon (!?)

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

From: cisco-faq
Date: 26 July 1994
Subject: Is there a World-Wide-Web (www) information source?

You can try the www homepage of this FAQ:

	http://www.panix.com/cisco-faq [no, it's not there yet]

or the cisco Information Archive hope page:

	http://sunsite.unc.edu/cisco/cisco-home.html

or the cisco Information Online (CIO) home page:

	http://www.cisco.com/


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

From: cisco-faq
Date: 5 July 1994
Subject: How can I get my cisco to talk to a third party router over 
a serial link?

You need to tell your cisco to use the same link-level protocol as the
other router; by default, ciscos use a rather bare variant of HDLC
(High-level Data Link Control) all link-level protocols use at some
level/layer or another. To make your cisco operate with most other
routers, you need to change the encapsulation from HDLC to PPP on the
relevant interfaces. For instance:

	sewer-cgs#conf t
	
	Enter configuration commands, one per line.
	Edit with DELETE, CTRL/W, and CTRL/U; end with CTRL/Z
	interface serial 1
	encapsulation ppp
	^Z

	sewer-cgs#sh int s 1
	
	Serial 1 is administratively down, line protocol is down 
	  Hardware is MCI Serial
	  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
	  Encapsulation PPP, loopback not set, keepalive set (10 sec)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]

If you're still having trouble, you might wish to turn on serial interface
debugging:

	sewer-cgs#ter mon
	sewer-cgs#debug serial-interface

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

From: cisco-faq
Date: 27 July 1994
Subject: How can I get my cisco to talk to a 3rd-party router over Frame Relay?

You should tell your cisco to use ``encapsulation frame-relay ietf''
(instead of ``encapsulation frame-relay'') on your serial interface
that's running frame relay if your frame relay network contains a
diverse set of manufacturers' routers. The keyword ``ietf'' specifies
that your cisco will use RFC1294-compliant encapsulation, rather than
the default, RFC1490-compliant encapsulation (other products, notably
Novell MPR 2.11, use a practice sanctioned by 1294 but deemed verbotten
by 1490, namely padding of the nlpid).  If only a few routers in your
frame relay cloud require this, then you can use the default
encapsulation on everything and specify the exceptions with the
frame-relay map command:

        frame-relay map ip 10.1.2.3 56 broadcast ietf
                                                 ^^^^

(ietf stands for Internet Engineering Task Force, the body which
evaluates Standards-track RFCs; this keyword is a misnomer as both
RFC1294 and RFC1490 are ietf-approved, however 1490 is most recent and
is a Draft Standard (DS), whereas 1294 is a Proposed Standard (one step
beneath a DS), and is effectively obsolete).

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

From: cisco-faq
Date: 26 July 1994
Subject: How can I use debugging?


The ``terminal monitor'' command directs your cisco to send debugging
output to the current session. It's necessary to turn this on each time
you telnet to your router to view debugging information. After that,
you must specify the specific types of debugging you wish to turn on;
please note that these stay on or off until changed, or until the
router reboots, so remember to turn them off when you're done.

Debugging messages are also logged to a host if you have trap logging
enabled on your cisco. You can check this like so:


	sl-panix-1>sh logging
	Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
	    Console logging: level debugging, 66 messages logged
	    Monitor logging: level debugging, 0 messages logged
	    Trap logging: level debugging, 69 message lines logged
	        Logging to 198.7.0.2, 69 message lines logged
	sl-panix-1>

If you have syslog going to a host somewhere and you then set about a
nice long debug session from a term your box is doing double work and
sending every debug message to your syslog server. Additionally, if you
turn on something that provides copious debugging output, be careful
that you don't overflow your disk (``debug ip-rip'' is notorious for
this).

One solution to this is to only log severity ``info'' and higher:

	sl-panix-1#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	logging trap info

The other solution is to just be careful and remember to turn off
debugging. This is easy enough with:

	sl-panix-1#undebug all

If you have a heavily loaded box, you should be aware that debugging
can load your router.  The console has a higher priority than a vty so
don't debug from the console; instead, disable console logging:

	cix-west.cix.net#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	no logging console

Then always debug from a vty.  If the box is busy and you are a little
too vigorous with debugging and the box is starting to sink, quickly
run, don't walk to your console and kill the session on the vty.  If
you are on the console your debugging has top prioority and then the
only way out is the power switch.  This of course makes remote
debugging a real sweaty palms adventure especially on a crowded box.
Caveat debugger!

Also, if you for some reason forget what the available debug commands are
and don't have a manual handy, remember that's what on-line help
is for. Under pre 9.21 versions, ``debug ?'' lists all commands. Under
9.21 and above, that gives you general categories, and you can check
for more specific options by specifying the category: ``debug ip ?''.

As a warning, the ``logging buffered'' feature causes all debug streams to
be redirected to an in-memory buffer, so be careful using that.

Lastly, if you're not sure what debugging criteria you need, you can
try ``debug all''. BE CAREFUL!  It is way useful, but only in a very
controlled environment, where you can turn off absolutely everything
you're not interested in.  Saves a lot of thinking.  Turning it on on a
busy box can quickly cause meltdown.

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

From: cisco-faq
Date: 5 July 1994
Subject: How can I use NTP (Network Time Protocol) with my cisco?

>What level of software is required for NTP support in
>a Cisco router?

9.21 or above.

>Which Cisco routers support NTP?

It is a software feature exclusively. Anything that supports
9.21 or 10 will run NTP (when running that s/w).

>How do I set it up?

The basic hook is:
	ntp server <host> [version n]
or
	ntp peer <host> [version n]

depending on whether you want a client/server or peer relationship.
There's a bunch of other stuff available for MD5 authentication,
broadcast, access control, etc.  You can also use the
context-sensitive help feature to puzzle it out; try "ntp ?" in config
mode.

You'll also want to play with the SHOW NTP * router commands.  Here
are two examples.

EXAMPLE 1:

router# show ntp assoc

      address         ref clock     st  when  poll reach  delay  offset    disp
+~128.9.2.129      .WWVB.            1   109   512  377    97.8   -2.69    26.7
*~132.249.16.1     .GOES.            1   309   512  357    55.4   -1.34    27.5
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

EXAMPLE 2:

router#show ntp stat
Clock is synchronized, stratum 2, reference is 132.249.16.1
nominal freq is 250.0000 Hz, actual freq is 249.9981 Hz, precision is 2**19
reference time is B1A8852D.B69201EE (12:36:13.713 PDT Tue Jun 14 1994)
clock offset is -1.34 msec, root delay is 55.40 msec
root dispersion is 41.29 msec, peer dispersion is 28.96 msec

For particular cisco NTP questions, feel free to ask in comp.dcom.sys.cisco.

For broader NTP info, see ftp://louie.udel.edu:pub/ntp/doc.  The file
clock.txt in that directory has info about various public NTP servers.
There is also information on radio time receivers that can be
connected to an NTP server (this is handy on private networks, if you
have an entire campus to get chiming, or if you become a hard core
chimer).

The "ntp clock-period" command is added automagically to jump-start
the NTP frequency compensation when the box is rebooted.  This is
essentially a representation of the frequency of the crystal used as
the local timebase, and may take several days to calculate otherwise.
(Do a "write mem" after a week or so to save a good value.)

Caveat: Note that the CS-500 will not be able to achieve quite the same
level of accuracy as other platforms, since its hardware clock
resolution is roughly 242Hz instead of the 1MHz available on other
platforms.  In practice this shouldn't matter for anyone other than
true time geeks.

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

From: cisco-faq
Date: 5 July 1994
Subject: Sample Cisco NTP Configurations

You will need to substitute your own NTP peers, timezones, and GMT
offsets into the examples below, of course.  Example 1 is in US Central
Time Zone, while example 3 is in US Pacific Time Zone.  Both account
for normal US Daylight Savings Time practices.

EXAMPLE 1 (Charley Kline):
...
clock timezone CST -6
clock summer-time CDT recurring
ntp source eth 0
ntp peer <host1>
ntp peer <host2>
ntp peer <host3>
...


EXAMPLE 2 (Tony Li):
...
ntp source Ethernet0/0
ntp update-calendar
ntp peer <host1> 
ntp peer <host2> prefer
...


EXAMPLE 3 (Dave Katz):
...
service timestamps debug datetime localtime
service timestamps log datetime localtime
clock timezone PST -8
clock summer-time PDT recurring
interface Ethernet0
ip address <mumble>
ntp broadcast
ntp clock-period 17180319
ntp source Ethernet0
ntp server <host1>
ntp server <host2>
ntp server <host3>

COMMENTS ON EXAMPLE 3: 
	The config file is commented with date and time (and user id,
if TACACS is enabled) when the system thinks the clock is accurate.
I've enabled timestamping of debug and syslog messages.  I send NTP
broadcast packets out onto the local ethernet.  I'm in Pacific
Standard Time, with U.S. standard daylight saving time rules.  I use
the IP address of the ethernet as the source for all NTP packets.


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

From: cisco-faq
Date: 5 July 1994
Subject: How do I avoid the annoying DNS lookup if I have misspelled a command?
 
By default, all lines are configured to automatically try a telnet
connection if the first word in a input line is not recognized as a
valid command.  You can disable this by setting "transport preferred
none" on every line (con, aux and vty). For instance:


	sl-panix-1#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	line vty 0 10
	transport preferred none


You can see the number of vty's currently configuered with ``show lines''

Also, you can suspend connect attempts with ^^ followed by "x", ie shift-cntrl-6 x.

[It has been suggested that ``no ip ipname-lookup'' to turn off IEN116
helps. I think this is the default -jh ]
 
------------------------------

From: cisco-faq
Date: 5 July 1994S
Subject: Tracing bad routing information

or: How do I find out which non-Cisco systems on my networks generate IP-RIP
   information without letting them mess up my routing tables.
 
Here you could work with a default administrative distance. Administrative distance is the
basis upon which the cisco prefers routing information of one protocol over another. In
this example:

	router rip
	network 192.125.254.0
	distance 255
	distance 120 192.125.254.17     ! list all valid RIP suppliers
	[...]

the value 255 has the implicit meaning of not putting this information
into the routing table. Therefore, setting an administrative distance
of 255 means that all RIP suppliers are by default accepted but their
information is not put into the routing table. The administrative
distance for the router 192.125.244.17 has been reset to the default
(for RIP) of 120, causing its routes to be accepted into the routing table.

Then you can look them up with ``show ip protocols'' and restore the
original administrative distance for the ones you want to fill in the
routing table.

The same results can be acheived with an ip access-list, but with that,
"show ip protocols" will only show the valid ones. But often it is more
useful to see which systems were generating routing information at all.

This trick works for other routing protocols as well, but please select
the proper adminstrative distance (rather than 120) for the protocol
you're using.

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

From: cisco-faq
Date: 5 July 1994
Subject: How to use access lists

                    Frequently Asked Questions
                    contributed by Howard C. Berkowitz
                    PSC International
                    hcb@world.std.com
                       @clark.net   [probably will be my permanent 
                                     personal account]
                    PSC's domain is in mid-setup

Where in the router are access lists applied?

    
    In general, Basic access lists are executed as filters on
outgoing interfaces.  Newer releases of the Cisco code, such as
9.2 and 10, do have increased ability to filter on incoming ports.
Certain special cases, such as broadcasts and bridged traffic,
can be filtered on incoming interfaces in earlier releases.
There are also special cases involving console access.

Rules, written as ACCESS-LIST statements, are global for the entire
Cisco box; they are activated on individual outgoing interfaces by
ACCESS-GROUP subcommands of the INTERFACE major command.
    Filters are applied after traffic has entered on an incoming
interface and gone through a routing process; traffic that originates in
a router (e.g., telnets from the console port) is not subject to
filtering.

             +-------------------+
             |     GLOBAL        |
             |                   |
             | Routing           |
             | ^  v       Access |
             | ^  v       Lists  |
             +-^--v--------^---v-+
             | ^  v        ^   v |
             | ^  v        ^   v |
A----------->|-|  |>>>>Access  >>----------->B
             |1        Group   2 |
<------------|                   |<-----------
             |                   |
             |                   |
             +-------------------+

    Some types of "filter," using "filter" as a broader class than
ACCESS-LIST, can operate on incoming traffic.  For example, the INPUT-
SAP-FILTER used for Novell networks is applied to Service Advertisement
Packets (SAP) seen at incoming interfaces.  In general, incoming
filtering can only be done for "system" rather than user traffic.

Rules of thumb in defining access lists.

    First, define what you want to do and in which directions.  An
informal drawing is a good first step.  As opposed to the usual
connectivity drawings among routers, it's often convenient to draw
unidirectional links between routers.
    Second, informally write out your filtering rules.  In general, it
is best to go from most specific to least specific. Modify the order of
writing things to minimize the number of rules needed.
    Third, determine which rules need to be on which routers.
Explicitly consider the direction of flow, and the possible existence of
additional paths that could inadvertently bypass a filter.

Can a Cisco router be a "true" firewall?

    This depends on the definition of firewall.  Some writers (e.g.,
Gene Spafford in _Practical UNIX Security_) define a firewall as a host
on which an "inside" and/or an "outside" application process run, with
application-level code linking the two.  For example, a firewall might
provide FTP access to the outside world, but it would not also provide
direct FTP service to the inside world.  To place a file on the FTP
external server, a designated user would explicitly log onto the FTP
server, transfer a file to the server, and log off.  The firewall
prevents direct FTP connectivity between the inside and outside
networks; only indirect, application-level connectivity is allowed.
   Firewalls of this sort are complemented by chokes, which filter on
network addresses and/or port numbers.  Cisco routers cannot do
application-level control with access control lists.
   Other authors do not distinguish between chokes and filters.  Using
the loose definition that a firewall is anything that selectively blocks
access from the inside to the outside, routers can be firewalls.


IP Specific
-----------

Can the "operand" field be used with a protocol keyword of IP to filter
on protocol ID?

    No.  Operand filtering only works for TCP and UDP port numbers.

How can I prevent traffic for a certain Internet application to flow in
one direction but not the other?

    Remember that Internet applications flow from client port to server
port.  Denying traffic from port 23, for example, blocks flow from the
client to the server.

             +-------------------+
             |                   |
A----------->|                   |----------->B
             |1                 2|
<------------|                   |<-----------
             |                   |
             +-------------------+

    If we deny traffic to Port 23 of address B by placing a filter at
interface 2, we have blocked A's ability to telnet to B, but not B's
ability to telnet to A.  A second filter at interface A would be needed
to block telnet in both directions.
    Assume that we only have the filter at interface 2.  Telnets to A
from B will not be affected because the filter at 2 does not check
incoming traffic.
-------

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

From: cisco-faq
Date: 26 July 1994
Subject: The cisco boot process


What really happens when a Cisco router boots, from boot start to live
interfaces?
 
First it boots the ROM os version.  It reads the config.  Now, it
realizes that you want to netboot.  It loads the netbooted copy in on
top of itself.  It then re-initializes the box and re-reads the
config.  Manly, yes, but we like it too....

[[
Ummm... in particular it loads the netbooted copy in as WELL as
itself, decompresses it, if necessary, and THEN loads on top of
itself.  Note that this is important because it tells you what the
memory requirements are for netbooting: RAM for ROM image (if it's a
run from RAM image), plus dynamic data structures, plus RAM for
netbooted image.
]]
 
The four ways to boot and what happens (sort of):
 
           I (from bootstrap mode)
 
The ROM monitor is running.  The I command causes the ROM monitor to
walk all of the hardware in the bus and reset it with a brute force
hammer.  If the bits in the config register say to auto-boot, then
goto B
 
           B (from bootstrap mode)
 
Load the OS from ROM.  If a name is given, tell that image to start
silently and then load a new image.  If the boot system command is
given, then start silently and load a new image.
 
           powercycle
 
Does some delay stuff to let the power settle.  Goto I.
 
           reload (from the EXEC)
Goto I.


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

From: cisco-faq
Date: 26 July 1994
Subject: Where can I get Cisco hardware?

[ It is with great relucatance that I list any one vendor. I would
appreciate some commentary as to whether doing so is a good idea. Also,
other vendors would be a good thing. ]

You might try:

   Comstar, Inc.
   5250 W. 74th Street
   Minneapolis, MN  55439
   P: 612-835-5502
   F: 612-835-1927
   Mr. Bill Lunger

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

From: cisco-faq
Date: 26 July 1994
Subject: Where can I get standards documents (RFCs, STDs, etc.)?

                   Where and how to get new RFCs
                   =============================

RFCs may be obtained via EMAIL or FTP from many RFC Repositories.  The
Primary Repositories will have the RFC available when it is first
announced, as will many Secondary Repositories.  Some Secondary
Repositories may take a few days to make available the most recent
RFCs.

Primary Repositories:


RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET,
NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or FTP.SESQUI.NET.


1.  DS.INTERNIC.NET - InterNIC Directory and Database Services

RFC's may be obtained from DS.INTERNIC.NET via FTP, WAIS, and
electronic mail.  Through FTP, RFC's are stored as rfc/rfcnnnn.txt or
rfc/rfcnnnn.ps where 'nnnn' is the RFC number.  Login as "anonymous"
and provide your e-mail address as the password.  Through WAIS, you
may use either your local WAIS client or telnet to DS.INTERNIC.NET and
login as "wais" (no password required) to access a WAIS client.  Help
information and a tutorial for using WAIS are available online.  The
WAIS database to search is "rfcs".

Directory and Database Services also provides a mail server
interface.  Send a mail message to mailserv@ds.internic.net and
include any of the following commands in the message body:

   document-by-name rfcnnnn      where 'nnnn' is the RFC number
                                 The text version is sent.

   file /ftp/rfc/rfcnnnn.yyy     where 'nnnn' is the RFC number.
                                 and 'yyy' is 'txt' or 'ps'.

   help                          to get information on how to use
                                 the mailserver.

The InterNIC Directory and Database Services Collection of Resource
Listings, Internet Documents such as RFCs, FYIs, STDs, and Internet
Drafts, and Publically Accessible Databases are also now available via
Gopher.  All our collections are waisindexed and can be searched from
the Gopher menu.

To access the InterNIC Gopher Servers, please connect to
"internic.net" port 70.

contact: admin@ds.internic.net


2.  NIS.NSF.NET

To obtain RFCs from NIS.NSF.NET via FTP, login with username
"anonymous" and password "guest"; then connect to the directory of
RFCs with cd /internet/documents/rfc.  The file name is of the form
rfcnnnn.txt (where "nnnn" refers to the RFC number).

For sites without FTP capability, electronic mail query is available
from NIS.NSF.NET.  Address the request to NIS-INFO@NIS.NSF.NET and
leave the subject field of the message blank.  The first text line of
the message must be "send rfcnnnn.txt" with nnnn the RFC number.

contact:  rfc-mgr@merit.edu


3.  NISC.JVNC.NET

RFCs can also be obtained via FTP from NISC.JVNC.NET, with the
pathname rfc/RFCnnnn.TXT.v (where "nnnn" refers to the number of the
RFC and "v" refers to the version number of the RFC).

JvNCnet also provides a mail service for those sites which cannot use
FTP.  Address the request to SENDRFC@JVNC.NET and in the subject field
of the message indicate the RFC number, as in "Subject: RFCnnnn" where
nnnn is the RFC number.  Please note that RFCs whose number are less
than 1000 need not place a "0". (For example, RFC932 is fine.)  No
text in the body of the message is needed.

contact: Becker@NISC.JVNC.NET


4.  FTP.ISI.EDU

RFCs can be obtained via FTP from FTP.ISI.EDU, with the pathname
in-notes/rfcnnnn.txt (where "nnnn" refers to the number of the RFC).
Login with FTP username "anonymous" and password "guest".

RFCs can also be obtained via electronic mail from ISI.EDU by using
the RFC-INFO service.  Address the request to "rfc-info@isi.edu" with
a message body of:

	Retrieve: RFC
	   Doc-ID: RFCnnnn

(Where "nnnn" refers to the number of the RFC (always use 4 digits -
the DOC-ID of RFC 822 is "RFC0822")).  The RFC-INFO@ISI.EDU server
provides other ways of selecting RFCs based on keywords and such; for
more information send a message to "rfc-info@isi.edu" with the message
body "help: help".

contact: RFC-Manager@ISI.EDU


5.  WUARCHIVE.WUSTL.EDU

RFCs can also be obtained via FTP from WUARCHIVE.WUSTL.EDU, with the
pathname info/rfc/rfcnnnn.txt.Z (where "nnnn" refers to the number of the
RFC and "Z" indicates that the document is in compressed form).

At WUARCHIVE.WUSTL.EDU the RFCs are in an "archive" file system and
various archives can be mounted as part of an NFS file system.
Please contact Chris Myers (chris@wugate.wustl.edu) if you want to
mount this file system in your NFS.

contact: chris@wugate.wustl.edu


6.  SRC.DOC.IC.AC.UK

RFCs can be obtained via FTP from SRC.DOC.IC.AC.UK with the pathname
rfc/rfcnnnn.txt.Z or rfc/rfcnnnn.ps.Z (where "nnnn" refers to the
number of the RFC).  Login with FTP username "anonymous" and password
"your-email-address".  To obtain the RFC Index, use the pathname
rfc/rfc-index.txt.Z.  (The trailing .Z indicates that the document is
in compressed form.)

SRC.DOC.IC.AC.UK also provides an automatic mail service for those
sites in the UK which cannot use FTP.  Address the request to
info-server@doc.ic.ac.uk with a Subject: line of "wanted" and a
message body of:

        request sources
        topic path rfc/rfcnnnn.txt.Z
        request end

(Where "nnnn" refers to the number of the RFC.)  Multiple requests may
be included in the same message by giving multiple "topic path"
commands on separate lines.  To request the RFC Index, the command
should read: topic path rfc/rfc-index.txt.Z

The archive is also available using NIFTP and the ISO FTAM system.

contact: ukuug-soft@doc.ic.ac.uk


7.  FTP.CONCERT.NET

To obtain RFCs from FTP.CONCERT.NET via FTP, login with username
"anonymous" and your internet e-mail address as password.  The RFCs
can be found in the directory /rfc, with file names of the form:
rfcNNNN.txt or rfcNNNN.ps where NNNN refers to the RFC number.

This repository is also accessible via WAIS and the Internet Gopher.

contact: rfc-mgr@concert.net


8.  FTP.SESQUI.NET

RFCs can be obtained via FTP from FTP.SESQUI.NET, with the pathname
pub/rfc/rfcnnnn.xxx (where "nnnn" refers to the number of the RFC and
xxx indicates the document form, txt for ASCII and ps for Postscript).

At FTP.SESQUI.NET the RFCs are in an "archive" file system and
various archives can be mounted as part of an NFS file system.
Please contact RFC-maintainer (rfc-maint@sesqui.net) if you want to
mount this file system in your NFS.

contact: rfc-maint@sesqui.net


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

Secondary Repositories:



Sweden
------
	Host:		sunic.sunet.se
	Directory:	rfc

	Host:		chalmers.se
	Directory:	rfc


Germany
-------
        Site:           EUnet Germany
	Host:           ftp.Germany.EU.net
        Directory:      pub/documents/rfc


France
------
	Site:		Institut National de la Recherche en Informatique
			et Automatique (INRIA)
	Address:	info-server@inria.fr
	Notes:		RFCs are available via email to the above
			address.  Info Server manager is Mireille 
			Yamajako (yamajako@inria.fr).


Netherlands
-----------
	Site:		EUnet
	Host:		mcsun.eu.net
	Directory:	rfc
	Notes:		RFCs in compressed format.


France
------
        Site:           Centre d'Informatique Scientifique et Medicale
                        (CISM)
        Contact:        ftpmaint@univ-lyon1.fr
        Host:           ftp.univ-lyon1.fr
        Directories:    pub/rfc/*       Classified by hundreds
                        pub/mirrors/rfc Mirror of Internic
        Notes:          Files compressed with gzip. Online
                        decompression done by the FTP server.
                        

Finland
-------
	Site:		FUNET
	Host:		funet.fi
	Directory:	rfc
	Notes:		RFCs in compressed format.  Also provides 
			email access by sending mail to
			archive-server@funet.fi.


Norway
------
	Host:		ugle.unit.no
	Directory:	pub/rfc


Denmark
-------
	Site:		University of Copenhagen
	Host:		ftp.denet.dk
	Directory:	rfc


Australia and Pacific Rim
-------------------------

	Site:		munnari
	Contact:	Robert Elz <kre@cs.mu.OZ.AU>
	Host:		munnari.oz.au
	Directory:	rfc
			rfc's in compressed format rfcNNNN.Z
			postscript rfc's rfcNNNN.ps.Z


United States
-------------

	Site:           cerfnet
        Contact:        help@cerf.net
	Host:           nic.cerf.net
        Directory:      netinfo/rfc

	Site:           NASA NAIC
        Contact:        rfc-updates@naic.nasa.gov
	Host:           naic.nasa.gov
        Directory:      files/rfc

	Site:           NIC.DDN.MIL (DOD users only)
        Contact:        NIC@nic.ddn.mil
        Host:           NIC.DDN.MIL
        Directory:      rfc/rfcnnnn.txt
        Note:           DOD users only may obtain RFC's via FTP 
                        from NIC.DDN.MIL.  Internet users should NOT
                        use this source due to inadequate connectivity.
          
	Site:           uunet
        Contact:        James Revell <revell@uunet.uu.net>
        Host:           ftp.uu.net
        Directory:      inet/rfc


UUNET Archive
-------------

     UUNET archive, which includes the RFC's, various IETF documents,
     and other information regarding the internet, is available to the
     public via anonymous ftp (to ftp.uu.net) and anonymous uucp, and
     will be available via an anonymous kermit server soon.  Get the
     file /archive/inet/ls-lR.Z for a listing of these documents.

     Any site in the US running UUCP may call +1 900 GOT SRCS and use
     the login "uucp".  There is no password.  The phone company will
     bill you at $0.50 per minute for the call.  The 900 number only
     works from within the US.


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

Requests for special distribution of RFCs should be addressed to
either the author of the RFC in question, to NIC@INTERNIC.NET.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@ISI.EDU.  Please consult "Instructions to RFC Authors",
RFC 1543, for further information.

Requests to be added to or deleted from the RFC distribution list should
be sent to RFC-REQUEST@NIC.DDN.MIL.

Changes to this file "rfc-retrieval.txt" should be sent to
RFC-MANAGER@ISI.EDU.

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

From: cisco-faq
Date: 27 July 1994
Subject: Future features in cisco software

[This could be more fleshed out, but Philip sent these in]

IPXWAN support added in 10.0
BGP4 support added in 10.0
Kerberos not yet available

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

From: cisco-faq
Date: 27 July 1994
Subject: How do cisco routers rate performance-wise?

Customers often ask about performance of the cisco routers and we shy
away from answering their questions because we don't know where to send
them.  Well, I have finally tracked down and can publish where Scott
Bradner keeps his results on the Internet.  You can find them on the
system hsdndev.harvard.edu in the /pub/ndtl.  There is a README file in
that directory that explains what is available.  In addition, cisco has
just started publishing a piece of literature called "The Harvard
Benchmark Test Results: Summary of Cisco Systems Performance".  The only
number I can find on the doc is Lit. #700901.  Don't know if you can
order it by this number, but at least I have a title to go on.



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

From: cisco-faq
Date: 26 July 1994
Subject: NOT YET!


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

From: cisco-faq
Date: 26 July 1994
Subject: NOT YET!


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

From: cisco-faq
Date: 26 July 1994
Subject: NOT YET!


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

From: cisco-faq
Date: 26 July 1994
Subject: NOT YET!


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

From: cisco-faq
Date: 26 July 1994
Subject: NOT YET!


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

From: cisco-faq
Date: 26 July 1994
Subject: NOT YET!


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

From: cisco-faq
Date: 5 July 1994
Subject: Acknowledgements.

The following people contributed to this FAQ, and their contributions
are greatly appreciated, both questions and answers

	"Ronnie B. Kon" <ronnie@cisco.com>
	Charley Kline <cvk@uiuc.edu>
	Dave Katz <dkatz@cisco.com>
	John Wright
	Pete Siemsen <siemsen@skat.usc.edu>
	Sanjay Rungta~ <srungta@sedona.intel.com>
	Steve Cunningham <steve@vf.ge.com>
	atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
	jerry@ksu.ksu.edu (Jerry Anderson)
	jhawk@panix.com (John Hawkinson)
	john@gulfa.ods.gulfnet.kw (John Temples)
	peter@ulisse.rhein-main.de (Peter Radig)
	tli@cisco.com (Tony Li)
	tom@park.uvsc.edu (Thomas R. Kimpton)
        Howard C. Berkowitz, PSC International, <hcb@world.std.com>
From: Alain Martineau <amartineau@MacMartineau.ccr.hydro.qc.ca>
From: Jim Forster <forster@cisco.com>
From: buk@taz.de ($ Burkhard Kohl)
From: Sean McGrath <SEAN@oak.his.ucsf.EDU>
From: Ran Atkinson <atkinson@sundance.itd.nrl.navy.mil>
From: Phillip Remaker <remaker@cisco.com>
From: john@cisco.com (John Wright)
From: warner@cats.ucsc.edu (Jim Warner)

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Aug 1994 08:40:20 +02
From:      Herman Van Uytven <Herman.VanUytven@cc.kuleuven.ac.be>
To:        comp.protocols.tcp-ip,comp.infosystems
Subject:   Re: What ever happened to whois++?

In article <32d688$dsl@zeus.swindon.rtsg.mot.com>,
jasonh@chineham.euro.csg.mot.com (Jason Haar) says:
>
>Says it all really. Is whois++ still been developed, or has X.500 won the
>day in the White Pages (-type) front?

I have to lookup addresses regularly, so I can say from myself I
have some experience in knowing what is used worldwide.

The one who wins so far is neither whois(++), neither X.500,
but gopher and qi/ph.

But can someone tell me what was really the purpose of whois++ ?
I thought it was to make a worldwide distributed whois service, but
the implementations you see are whois servers which consult X.500 data
(and then you have indeed a worldwide distributed whois server, but
 I don't think this was the original purpose ?).
>
>--
>
>Cheers,
>
>Jason
>+------------------------------+------------------------------------------+
>| Jason Haar, European SysAdmin   Phone: + 44 (256) 790111                |
>| Motorola Cellular Subscriber      Fax: + 44 (256) 790519                |
>| Basingstoke, Hampshire                                                  |
>| RG24 0GY,  ENGLAND           Internet: jasonh@chineham.euro.csg.mot.com |
>+------------------------------+------------------------------------------+

------------------------------------------------------------------------
| Herman Van Uytven              Generic E-mail :                      |
| Academic Computing Center      Herman.VanUytven@cc.kuleuven.ac.be    |
| K.U.Leuven                     Tel: (+32) (16) 286611 local 2225     |
| Willem De Croylaan 52-a        Fax: (+32) (16) 207168                |
| B-3001 Heverlee (Leuven)       EARN/BITNET: systhvu@blekul11         |
| Belgium                        Internet: systhvu@cc1.kuleuven.ac.be  |
|       Postmaster and newsmaster for (cc1).kuleuven.ac.be             |
 ------------------------------------------------------------------------

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1994 16:57:02 GMT
From:      kerch@reynaldo.PARC.Xerox.Com (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: help please-daemon process on UNIX

>>>>> "Stanley" == Stanley Chan <schan@gcau.com.au> writes:
In article <1994Aug12.012951.22567@gcau.com.au> schan@gcau.com.au (Stanley Chan) writes:

I strongly recommend W. R. Steven's "Advanced Unix Programming"; it
has a chapter on writing Unix daemon processes.
   
    Stanley> 3) The program should be setuid and own by root if you
    Stanley> want it to do some system functions, this is what a
    Stanley> daemon is for generally.  You can do this inside the
    Stanley> program.

NO!  No no no no!  NEVER EVER make a program setuid root unless it
ABSOLUTELY POSITIVELY has to be root.  You will usually find that
setgid  suffices.  The programs that need to read kernel memory (such
as ps) are no longer setuid root in modern systems, but setgid kmem,
where /dev/kmem is made group kmem and group readable.

This technique makes your system incrementally more secure.

If you think your program ABSOLUTELY POSITIVELY has to be root, you
are almost certainly wrong.  Think about it for a few days before you
commit.  Setuid root programs are very difficult to write securely,
and every one is therefore a lurking security hole.

    Stanley> You should be able to kill it as root if you have not
    Stanley> ignore all signals.

You can always kill any process as root.  Signal -9 cannot be caught
or ignored.

  --berry
--

Berry Kercheval :: kerch@parc.xerox.com 
"WARNING: Objects in calendar are closer than they appear!"



-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      13 Aug 1994 18:50:45 GMT
From:      kannan@nestow.cs.ualberta.ca (Kannan Thiruvengadam)
To:        comp.protocols.tcp-ip
Subject:   Documents on Multicast

Hi

I am looking for documents on IP Multicast. I need, among others, details 
as to how to form temporary multicast addresses.   

Thanks.

- Kannan

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Aug 1994 05:40:35 GMT
From:      fischman@auvax1.adelphi.edu
To:        comp.protocols.tcp-ip
Subject:   FREE TCP/IP

	Could someone please tell me if there is any sort of 
"public domain" TCP/IP software that I can use to communicate
with my NetWare v3.11 server, and where I can get it?
				Thanks...

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 1994 11:29:41 GMT
From:      paf@staff.nada.kth.se (Patrik Faltstrom)
To:        comp.protocols.tcp-ip,comp.infosystems
Subject:   Re: What ever happened to whois++?

In article <94225.084020SYSTHVU@cc1.kuleuven.ac.be> Herman Van Uytven <Herman.VanUytven@cc.kuleuven.ac.be> writes:

>I have to lookup addresses regularly, so I can say from myself I
>have some experience in knowing what is used worldwide.
>
>The one who wins so far is neither whois(++), neither X.500,
>but gopher and qi/ph.
>
>But can someone tell me what was really the purpose of whois++ ?
>I thought it was to make a worldwide distributed whois service, but
>the implementations you see are whois servers which consult X.500 data
>(and then you have indeed a worldwide distributed whois server, but
> I don't think this was the original purpose ?).

I agree that it's gopher together with for example ph which is what
is used today, but what all services, X.500, whois and ph lacks
is a mechanism for automatic requerying a second server if the first
one doesn't have the record you are searching for. Whois++ does
have this indexing mechanism and that is why I think that the
Whois++ protocol will be used.

But, as you almost say, it doesn't matter what database you are using
in the bottom. It might be a dbm, sql or even an X.500 database. It's
the client <-> server and server <-> server protocol together with the
indexing service (the centroid mechanism) which makes whois++ strong.

	paf

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Aug 1994 12:58:21 GMT
From:      larry@gator.rn.com (Larry D Snyder)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   SLIP verses PPP

I'm running SLIP that came with Dell 2.2 here to connect
my class C domain to the internet

If I were to use PPP verses SLIP, would I notice any difference in 
available bandwidth assuming the same traffic?

-- 
Larry Snyder
larry@gator.rn.com

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 1994 21:23:19 -0400
From:      cnordin@charm.net (Craig Nordin)
To:        comp.protocols.tcp-ip
Subject:   Re: FREE TCP/IP

fischman@auvax1.adelphi.edu writes:

>	Could someone please tell me if there is any sort of 
>"public domain" TCP/IP software that I can use to communicate
>with my NetWare v3.11 server, and where I can get it?
>				Thanks...

Whew, tall order!

I'm running UnixWare and it can talk IP as well as Netware 3.11.
Maybe that is an option...

You might find some leads on the web page I've been maintaining:

          http://www.charm.net/ppp.html

-- 

See the Emerald on the Matrix?   Baltimore, Maryland Access to the Internet
   That's Charm.Net Hon!       E-Mail: info@charm.net  Voice:(410) 558.3900
  http://www.charm.net/    "guest" login, no password   Data:(410) 558.3300

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 1994 21:26:44 -0400
From:      cnordin@charm.net (Craig Nordin)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

>I'm running SLIP that came with Dell 2.2 here to connect
>my class C domain to the internet
 
>If I were to use PPP verses SLIP, would I notice any difference in 
>available bandwidth assuming the same traffic?

PPP usually is more comparable to CSLIP, so you might find some
improvement.   If what you have works OK, I'd say you could spend
your time better elsewhere.

Different software (regardless of it being for PPP/SLIP/CSLIP) will
perform at different levels of efficiency.


-- 

See the Emerald on the Matrix?   Baltimore, Maryland Access to the Internet
   That's Charm.Net Hon!       E-Mail: info@charm.net  Voice:(410) 558.3900
  http://www.charm.net/    "guest" login, no password   Data:(410) 558.3300

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Aug 1994 16:29:29 GMT
From:      doug@eng.auburn.edu (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: File Transfer between Macs and Suns

In article <hayes-080894113814@h00c6825.es.hac.com>, hayes@rassp.hac.com (Brian S. Hayes) writes:
> I'm writting an application that will need to perform file transfers from 
> the Sun to a Mac.  Is there any source code out there that deals with this?
> I would appreciate any pointers on this subject.
> 
> end -- Brian                                                  \\:^)
> Brian S. Hayes             | Internet : hayes@rassp.hac.com
> Hughes Aircraft Company    | MicroSoft: bhayes@msmail4.hac.com
> MS: RE/R01/A528            | Voice    : (310) 334-8433
> PO Box 92426               | RASSP Hot Line: (310) 334-5404
> Los Angeles, CA 90009-2426 | RASSP Fax     : (310) 334-1672

This could be a bit simplistic, but what about NCSA telnet and ftp?
(you can ftp to your mac)
-- 
____________________________________________________________________________
Doug Hughes					Engineering Network Services
System/Net Admin  				Auburn University
			doug@eng.auburn.edu
"The Light at the end of the tunnel is the headlamp of an oncoming train"

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 1994 19:16:53 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.unix.ultrix,comp.sys.dec,comp.protocols.tcp-ip
Subject:   Arrggh, DEC your telnet is brain-damaged!

If the terminal's baud rate is > 9600 baud, telnet sends

    -1,-1

as the input/output speeds in the terminal speed option sub-negotiation.

Hint to those who happen to have source: just above the routine
TerminalSpeeds() in sys_bsd.c, someone with clue shortage put:

#ifndef B19200
# define B19200 B9600
#endif
#ifndef B38400
# define B38400 B19200
#endif

rather than, say:

#ifndef B19200
# define B19200 EXTA
#endif
#ifndef B38400
# define B38400 EXTB
#endif

thus transforming the last few elements of the array "termspeeds"
from:
        { 4800,  B4800 },  { 9600,  B9600 }, { 19200, B19200 },
        { 38400, B38400 }, { -1,    B38400 }
to:
        { 4800,  B4800 },  { 9600,  B9600 }, { 19200, B9600 },
        { 38400, B9600 },  { -1,    B9600 }

thus returning -1 for any speed > B9600.

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

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Aug 1994 21:11:01 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

In article <CuJ01A.AF9@gator.rn.com> larry@gator.rn.com (Larry D Snyder) writes:
>I'm running SLIP that came with Dell 2.2 here to connect
>my class C domain to the internet
>
>If I were to use PPP verses SLIP, would I notice any difference in 
>available bandwidth assuming the same traffic?

Assuming no glaring bugs, assuming that neither the modems nor the phone
lines are changed, assuming both PPP and SLIP use Van Jacobson header
compression for TCP/IP, and assuming reasonable MTU/MRUs, then no
difference in speed is likely to be detectable, not to mention noticable.

As far as moving bits is concerned, PPP spends about 3 more bytes/packet,
but with packet sizes of 256 to 1500, that is less than likely noise in
measurements.


Vernon Schryver    vjs@rhyolite.com

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      14 Aug 94 22:53:24 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP software latency (Was: Speeding up PPP connection..)

In article <Cu66so.GtG@calcite.rhyolite.com> you write:
>TCP can be run in very few instructions.  ...
>It is possible to implement TCP/IP so that around 100 instructions are
>required between the user operating system request and the appearance
>of the data on the Ethernet or vice versa.  Note that I wrote
>"instructions", not "lines of C." (I don't have the currently standard
>reference to the paper in which Van Jacobson has reported his numbers.
>Does someone else?)   

Sorry about this.  This article has NOTHING to do with zmodem or PPP,
but I have redirected this away from the less relevant regions.  I,
too, would like to find out what paper Van Jacobson reported these
numbers in (is there one?)?  I've seen talk notes where he described
getting around 100 instructions for the TCP and IP layers only
(ftp.ee.lbl.gov:vj-nws93-1.ps); I have never seen numbers for sockets,
driver, synchronization, or syscall/interrupt processing.

I have tried latency-reducing measures myself, and I have
minimal-packet-size, receive-side UDP (I agree that fast send-side is
relatively easy, and I'm not all that interested in TCP), IP, and LLC
(if_ethersubr.c) down to a total of around 40 instructions.  But
sockets and drivers are each over 300 instructions, NOT including
synchronization or copyout overhead (didn't see much point in counting
since the point about the mismatch is already made).  It is true that
the sockets and driver are not COMPLETELY optimal yet, but I see a
floor coming at 200 instructions for each.  I assume no hysteresis,
since there is no common workstation workload I am aware of that
produces a bombardment of back-to-back small packets that go to user
level (this note is not about routing).

More food for thought: despite the reduction to 650 instructions in a
certain dubious sense, a 150-cyle-per-second, superscalar Alpha
3000/500 seems to take about 70 microseconds to execute the
receive side software (HINT: it's way more'n 650 instructions, and
there are a lot of stalls waiting for data).

							Jon
-- 
WWW/Mosaic Home Page:  http://www-cse.ucsd.edu/users/jkay
Email:                 jkay@cs.ucsd.edu

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 11:27:04 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: Port TCP/IP apps to X.25

In article <32nt6a$er@crchh81b.bnr.ca> dawkins@bnr.ca (Spencer Dawkins) writes:
>
>X.25 switches from reputable vendors (including Northern Telecom's DPN) do
>everything possible to keep from sending RESETs, but if you don't have control
>of both ends of your network, and/or you expect to have somthing that works
>over any arbitrary network topology of X.25 networks, you still need a
>transport layer that survives network-level RESETs and (in a connection-
>oriented environment) network disconnects.

   Literally you need something with some kind of data sequencing 
   above X.25 which can detect and recover lost data due to RESET's.
   The algorithms used in most X.25 devices have the nasty habit, once
   congestion is sufficient to cause a RESET sequence, of using a
   "fairness algorithm" and picking the circuit paths with the most
   data queued to reset.    

   You also need a layer which can detect a locked Virtual Circuit and
   re-transmit or clear, as standard CCITT X.25 doesn't have any
   mandated timer protection for DATA packets on a VC.  

>Don't think about changing IP to X.121 globally and hoping things will work.
>TCP knows about IP addresses, you know that, but many applications cache
>IP addresses (like, FTP). You will probably have to change A LOT. For a 
>complete list, look at the Firewalls discussions about proxy applications
>that are needed when firewalls fiddle with IP addresses.

  No, what I meant was that if they administer their own X.25 network
  and thus have full control of the X.121 addressing in it, they can
  do what Milnet does and use an algorithm to derive IP from X.121
  and vice versa. 

>Running two network layers (X.25 and IP) may seem wrong (overhead, twice
>the chances for cockpit error), and running connection-oriented TCP over
>connectionless IP over connection-oriented X.25 may seem wrong (why pay
>h/w and throughtput costs for X.25 services you're going to throw away
>at the IP level), but it's what I'd try first. It's well understood, because
>(as the previous poster said) lots of people have done it for 20 years.


  Or that the ISO folks in their version of X.25 have a somewhat
  "thicker" and more robust service interface which covers many
  of the things lacking from ordinary X.25 which keep it from being
  a true robust ISO network layer.  

  The BEST thing about doing CSNET style IP on X.25 is that you can
  buy it from just about everyone and connect reliably to just
  about everyone.    That way if your needs of any type change in the
  future, you don't need to start all over from scratch again. 



-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 00:41:34 GMT
From:      senthil@cs.washington.edu (Senthilvasan Supramaniam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.client-server
Subject:   [Q] Connection to a cluster of servers


        I was wondering if anyone could give me some pointers
on how I can automatically forward a connection request to one server
to another server. It should hopefully be transparent to the client.
Sort of like telneting to a cluster of machines and you get
connected to the least loaded machine. I'm talking at the socket
level interface (i.e., accept).


Thanks
-Senthil.

-- 
____________________________________________________________________
S. Senthilvasan            Internet: senthil@cs.washington.edu 
Seattle, WA                Voice:    (206) 547-4532  (home)               
____________________________________________________________________

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 09:13:30 -0500
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: Port TCP/IP apps to X.25

Everything in Lon's followup was correct, but I have a couple of comments 
that might help you appreciate what's being discussed...

In article <32gije$gio@pyrnova.mis.pyramid.com>,
Lon Stowell <lstowell@pyrnova.mis.pyramid.com> wrote:
>In article <wchenCuC4oM.CFA@netcom.com> wchen@netcom.com (Wen Chen) writes:
>>Hi,
>>
>>We have developed our distributed application for TCP/IP protocol.  Now, 
>>we need to port our code to X.25.  Our goal is to keep the change to our
>>code minimum it at all.
>
>  The simplest method would be to just run tcp/ip on top of X.25.
>
>  Otherwise you will rapidly discover the difference between a REAL
>  socket type interface of tcp/ip with the protocol protection and
>  the underlying layers compared to a hack from a nameless vendor
>  who put a socket interface right on top of X.25--which is nothing
>  but a glorified link layer.   
>

The "difference between a REAL..." is that X.25 does not provide what ISO
flacks call a "transport layer". In particular, an X.25 network can RESET
a connection, which basically says "you still have a connection with the
far end; but restart your sequence numbering at zero". When this happens,
you are clueless as to what happened to packets you sent into the network;
specifically, you don't know whether the far-end saw them or not, and there
is no way to ask. 

Vendors like Hewlett-Packard have socket interfaces for X.25 (PROTO_CCITT),
but the ones I've seen are really for X.25, not for (say) TP2 over X.25, so 
they don't rovide any transport-level functionality. So
your application will suddenly start seeing things like RESETs.

X.25 switches from reputable vendors (including Northern Telecom's DPN) do
everything possible to keep from sending RESETs, but if you don't have control
of both ends of your network, and/or you expect to have somthing that works
over any arbitrary network topology of X.25 networks, you still need a
transport layer that survives network-level RESETs and (in a connection-
oriented environment) network disconnects.


>>For those who are familiar with the protocol stack, do you think if we 
>>can approach it by pushing a TCP stream module on top of the X.25 
>>driver/module.  We are relatively new to this territory.  Any suggestions 
>>are appreciated. 
>
>  Its a bit more complicated than that, but not rocket science.  If
>  your X.25 must traverse public packet networks, you will need a
>  "miracle" layer which puts your tcp stuff in and out of packets as
>  well as magic to map X.121 addresses, X.25 parameters, X.25
>  facilities, call request handling etc.   If this is a private
>  network you may be able to do what milnet does and use an algorithm
>  to map the internet address to the X.25 dte address.  

Don't think about changing IP to X.121 globally and hoping things will work.
TCP knows about IP addresses, you know that, but many applications cache
IP addresses (like, FTP). You will probably have to change A LOT. For a 
complete list, look at the Firewalls discussions about proxy applications
that are needed when firewalls fiddle with IP addresses.

>
>  Of course if your application is pretty much tty semantics it should
>  be no big deal running it on X.25/X.29.  
>
>  If you choose to go with tcp/ip on X.25 you may want to get not only
>  the RFC but also the old 'CSNET' white papers if you intend to
>  implement the stack yourselves...otherwise the simplest thing is to
>  contact your vendor(s) and see if they have the option to run tcp/ip
>  on X.25.

Running two network layers (X.25 and IP) may seem wrong (overhead, twice
the chances for cockpit error), and running connection-oriented TCP over
connectionless IP over connection-oriented X.25 may seem wrong (why pay
h/w and throughtput costs for X.25 services you're going to throw away
at the IP level), but it's what I'd try first. It's well understood, because
(as the previous poster said) lots of people have done it for 20 years.

DoD computer systems have X.25 as their lowest common denominator (you can
get an X.25 card for ANYTHING), and all their interesting applications run
over TCP/IP, so people have been thinking about TCP/IP over X.25 for years.

Spencer
-- 
-  Spencer Dawkins	Internet: dawkins@bnr.ca   (214) 684-4827           -
-  "Everything I need to know, I learned reading .signatures on the net"    -

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 02:46:55 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: FREE TCP/IP

In article <CuIFro.Dtr@adl33cc.adelphi.edu> fischman@auvax1.adelphi.edu writes:

	   Could someone please tell me if there is any sort of 
   "public domain" TCP/IP software that I can use to communicate
   with my NetWare v3.11 server, and where I can get it?

Sure.  Get the Crynwr packet driver collection.  In it you'll find a
bunch of Ethernet drivers.  You'll also find an IPX (in PDIPX103.ZIP)
that runs over those drivers (it expects to use IEEE_802.3 binding).
You'll also find SOFTWARE.DOC, which lists free software that runs
over packet drivers.

And once you outgrow the free stuff, there are a number of commercial
TCP/IP packages that run over packet drivers.

--
-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 09:55:24 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: IPSEC Info Sources?

In <32mvff$lf5@sun.cais.com> chris2@v-one.com (CLL) writes:

>I am looking for information about the IPSEC working group of the IETF.
>This is the group working on encryption standards for secure IP packet
>transport. Any pointers would be greatly appreciated. 

Attached is a pointer.

--
John Hawkinson
jhawk@panix.com

Internet Protocol Security Protocol (ipsec)
-------------------------------------------
 
 Charter 
 
 Current status: active working group
 
 Chair(s):
     James Zmuda <zmuda@spyrus.com>
     Paul Lambert <paul_lambert@email.mot.com>
 
 Security Area Director(s): 
     Jeffrey Schiller  <jis@mit.edu>
 
 Mailing lists: 
     General Discussion:ipsec@ans.net
     To Subscribe:      ipsec-request@ans.net
     Archive:           ftp.ans.net:~/pub/archive/ipsec
 
Description of Working Group:
 
Rapid advances in communication technology have accentuated the need
for security in the Internet.  The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP.
A security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.  The 
protocol formats for the IP Security Protocol (IPSP) will be independent of
the cryptographic algorithm.  The preliminary goals will specifically 
pursue host-to-host security followed by subnet-to-subnet and 
host-to-subnet topologies.  

Protocol and cryptographic techniques will also be developed to support
the key management requirements of the network layer security.  The key
management will be specified as an application layer protocol that is
independent of the lower layer security protocol.  The protocol will
initially support public key-based techniques.  Flexibility in the
protocol will allow eventual support of Key Distribution Center (KDC -
such as Kerberos) and manual distribution approaches.

 Internet-Drafts:

  No Current Internet-Drafts.

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 05:46:22 GMT
From:      chris2@v-one.com (CLL)
To:        comp.protocols.tcp-ip
Subject:   IPSEC Info Sources?

I am looking for information about the IPSEC working group of the IETF.
This is the group working on encryption standards for secure IP packet
transport. Any pointers would be greatly appreciated. 

Chris


-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 94 14:25:28 -0500
From:      imhw400@indyvax.iupui.edu (Mark H. Wood)
To:        comp.protocols.tcp-ip,comp.infosystems
Subject:   Re: What ever happened to whois++?

In article <32kv76$hqo@news.kth.se>, paf@staff.nada.kth.se (Patrik Faltstrom) writes:
> I agree that it's gopher together with for example ph which is what
> is used today, but what all services, X.500, whois and ph lacks
> is a mechanism for automatic requerying a second server if the first
> one doesn't have the record you are searching for. Whois++ does
> have this indexing mechanism and that is why I think that the
> Whois++ protocol will be used.

Hmmm, I thought that the X.500 DUA was supposed to continue rooting through the
DIT until it either finds a hit or gets a definitive no-answer?  Why is all
that replication stuff in there otherwise?
-- 
Mark H. Wood, Lead Systems Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  MWOOD@INDYVAX.IUPUI.EDU       BITNET:  MWOOD@INDYVAX
"I live the greatest adventure one could ever wish." - a tosc

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 13:22:58
From:      padgett@141.240.2.145 (Padgett 0sirius)
To:        comp.protocols.tcp-ip
Subject:   Re: Documents on Multicast

In article <32j4m5$bqu@scapa.cs.ualberta.ca> kannan@nestow.cs.ualberta.ca (Kannan Thiruvengadam) writes:
>I am looking for documents on IP Multicast. 

Check out RFC1112.

			A. Padgett Peterson, P.E.
                        Cybernetic Psychophysicist
			   We also walk dogs
	 	       PGP 2.4 Public Key Available

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 12:20:22 GMT
From:      scum@pcthree.com (Steve Monroe)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

larry@gator.rn.com (Larry D Snyder) writes:

>I'm running SLIP that came with Dell 2.2 here to connect
>my class C domain to the internet
 
>If I were to use PPP verses SLIP, would I notice any difference in 
>available bandwidth assuming the same traffic?

That's if you can find it to run on your Dell 2.2.  PPP on PC/Unix
seems to be largely ignored by commercial and free markets.

BTW, let me know if you do..


-- 
Steven C. Monroe            VOICE:(703)406-2082                PC Three, Inc.
scum@pcthree.com             FAX:(703)406-2078                  P.O. Box 1644
                                                              Herndon, VA 22070

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 13:25:15 GMT
From:      spidey@rtp.vnet.ibm.com
To:        comp.protocols.tcp-ip
Subject:   Re: RPC (Remote Procedure Call) Request for information

In <larkinrp.776757065@marsh>, larkinrp@cs.curtin.edu.au (Richard Larkin) writes:
>I would like to know if anyone has any good sites/examples/tutorials on
>programming with RPC. It is for an assignment in my course and I am too
>stingy to buy the RPC book (O'reilly and associates) and was wondering if
>there are any good information sites available that you guys know of.
>
>Much help appreciated in advance thanking you.
>
>
>Richard Larkin


Richard, Look for Power Programming with RPC by John Bloomer.
It is published by OReilly and Associates and is part of the UNIX Network
Programming series of books.   Godd examples and helpful hints.

Jim Sliwa

Happy RPCing
--- When the snake and the mongoose meet the mongoose prevails
---     For it is the jaws with which we speak 
---     not the venom with which we say it
---     that determines our strength!




-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 14:25:04 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.client-server,alt.cyberspace,alt.politics.datahighway,alt.security,alt.wired,comp.protocols.tcp-ip
Subject:   Status of RFCs

% PLease indulge me, what are RFCs?

>> Request For Comments, which is an explicit, formal internet standard.
>> 
>> -marc
 
>ahhh, i think i've just about always read in the rfcs a statement to the
>effect that "this does not establish an internet standard."  they are,
>after all, requests for COMMENTS, not established standards.

Umm.  Neither of the above answers is quite correct, though both are
partly correct.

First, acronym expansion:
	RFC == "Request for Comments"
	I-D == "Internet Draft"

  RFCs are a series of documents by and for the Internet community put
out electonically at well known archive sites.  Some RFCs do specify
formal Internet standards.  Many RFCs do not specify any kind of
standard and instead provide information, provide humour, or describe
experimental protocols.  Anyone can put out an RFC.  Some RFCs (e.g.
those describing NFS) have the formal status of Informational but in
practice are de facto industry standards without being formal Internet
standards.  An RFC entitled "IAB Official Standards" is issued
periodically and this document definitively describes the current
status of all standards-track RFCs.  RFCs are never modified once
issued, but an RFC may be superceded by a later RFC.  The RFC name
should not be taken overly literally.  While comments are always
welcome, an RFC is not literally always intended primarily to solicit
comment.  The choice of name is somewhat historical. One reason for
that name is that the name often makes publication releases processes
of large corporations and government organisations easier.

  Standards-track RFCs generally contain words in the "Status of this
Memo" section indicating that they are on the "standards track" or are
"standards".  However, the status of some RFCs has changed after
publication (e.g. from a standards-track document to a historical
no-longer standards track document).  One should always check the most
recent online "IAB Official Standards" RFC to ascertain the standards
status of a particular RFC.

  There is an RFC out that describes the Internet standards process in
some gory detail.  Interested folks should consult it for more information.
Also, there is an RFC providing information to would-be RFC authors.

Ran
atkinson@itd.nrl.navy.mil

[Followups have been redirected]

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 14:31:21 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software latency (Was: Speeding up PPP connection..)

I think the paper is

David Clark, Van Jaconson, John Romkey and Howard Salwen, "An Analysis
of TCP Processing Overhead" IEEE Communications Magazine pp 22-29 June
1989.


Once a connection is established, most of the information in a header
is redundant. You can also predict what the next header looks
like. Therefore you construct a bit mask of the expected header, and
do a compare. If the header matches what you expect, you win (and
don't have to split up the bits). Else, you have to break up the bits
and find out what the packet really contains. The trick is to optimize
so that if you get what you expect, you do the least amount of work.


From Dave CLark's "Art of Protocol Performance" course notes:

Best case for TCP processing is
	IP: 60 instructions
	Timer: 41 to reset
	Buffer: 40 to send, 35 to receive, 30 to free

Best Guess Bottom Line: 357 Instructions total


The real bottleneck, in Dr. Clark's mind, is memory to memory
transfer. And the speed of light.

On the other hand, I don't know if any vendor is shipping a version of
TCP similar to Van's experimental version.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 14:50:48 GMT
From:      bracke@ameris.ameritech.com (Norbert R. Bracke)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   HELP: MacTCP and Localtalk

I need some help installing MacTCP on a IIci, PLEASE.
I've had no problem on a mac running ethertalk or tokentalk,
but get a message 'Unable to load MacTCP drivers' from the
MacTCP Ping on the IIci's running Localtalk.  I have updated
with the latest NSI Localtalk 58.2.2 and patched MacTCP 2.0.4
What am I doing wrong???
Please e-mail any advice:  BRACKE@ameris.ameritech.com


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 16:03:23 GMT
From:      larry@eco.twg.com (Lawrence B. Henry III)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.client-server
Subject:   Re: [Q] Connection to a cluster of servers


In article <CuJwLr.L4A@beaver.cs.washington.edu>, senthil@cs.washington.edu (Senthilvasan Supramaniam) writes:
|>
|>        I was wondering if anyone could give me some pointers
|>on how I can automatically forward a connection request to one server
|>to another server. It should hopefully be transparent to the client.
|>Sort of like telneting to a cluster of machines and you get
|>connected to the least loaded machine. I'm talking at the socket
|>level interface (i.e., accept).
|>
|>
|>Thanks
|>-Senthil.
|>

Senthil,
	We have implemented something like this in our PathWay for OpenVMS 
product. We call it cluster load balancing... We accomplished this by
enhancing out NAME Server to allow for the inclusion of a cluster name, which
points to a list of real machines. The resolution of this cluster name changes
to and ordered list starting with the least loaded of the machines in 
the list. Our name server takes care of all of the details. Drop me a note 
if you want more details; I think I have a PostScript file that documents this
in more detail.

-Larry.
The Wollongong Group.


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 16:17:36 GMT
From:      nagendra@csa.bu.edu (nagendra mishr)
To:        comp.protocols.tcp-ip
Subject:   Re: setsockopt not working in TCP/IP for OS2

In article <4aZIkmoZjmY0069yn@msen.com> brain@msen.com (Jim Brain) writes:
...
   In TCP/IP for OS/2, I want to start multiple server apps listening on the
   same address/port.  Note that each server is a separate executable.
...

I hope that all your executables are not on the same machine....


Nagendra
nagendra@csa.bu.edu

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 16:23:15 GMT
From:      nagendra@csa.bu.edu (nagendra mishr)
To:        comp.protocols.tcp-ip
Subject:   bcast packet filtering for routers...


we're running a novell network as well as a tcp/ip on some
machines...  Our server will be doing the routing between three
different subnets and I would like to know if it is possible to filter
out all broadcasts except for a few on specified ports between the two
subnets..

Anyonw know if this is possible and if so what sources of information
should I be reading...

Thanks for any help..

Nagendra
nagendra@csa.bu.edu


-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 17:09:18 GMT
From:      shark@netcom.com (Stefan Sharkansky)
To:        comp.protocols.tcp-ip,comp.unix.programmer,comp.sys.ncr
Subject:   Re: Binding a DGRAM (UDP) socket?

In article <KSTAILEY.94Aug12101242@leidecker.std.com> kstailey@leidecker.std.com (Kenneth Stailey) writes:
>
>>I am having a problem with UDP sockets in the context of broacast addrs.
>>I am implementing a dynamic BOOTP server, and one of the problems I 
>>need to solve is "Which interface did the bootp request come in on?"
>>
>>In our environment, bootp is being used to assign the IP addr, and as
>>such, the client is setting the source IP address to INADDR_ANY(0.0.0.0).
>>It is also setting the destination addr to broadcast, as it has no
>>knowledge of who the bootp server might be.
>>
>>When the request comes to the server, if the server is listening on 
>>a socket bound to INADDR_ANY, it hears the request just fine.  However,
>>if I listen on a set of sockets, each bound to the addr of one of the
>>interfaces, I never see the requests.
>>
>>Is there some way to determine which interface the datagram came in on?

I solved the same problem by having the server dedicate a socket to each
network interface (with none bound to INADDR_ANY).  You can use the
ioctl()s defined in /usr/include/sys/sockio.h to discover all of your
interfaces.

>
>Are you doing an accept() after the listen()?
>Doesn't accept() return the remote address?

accept() and listen() are completely irrelevant here, since they apply to
TCP only and NOT UDP, which is what BOOTP uses.

--

Stefan Sharkansky
Prospero Systems Research, Inc.
USMAIL	520 Frederick St. Box 19, San Francisco, CA 94117
VOICE	(415) 731-8114		FAX  (415) 731-3395
E-MAIL	shark@netcom.COM


-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 94 01:09:43 PDT
From:      Craig Morley <cmorley@hookup.net>
To:        comp.security.unix,comp.protocols.tcp-ip,comp.infosystems.www,alt.internet.services
Subject:   Re: Bypassing internet firewall


In article <32r8jj$flj@ucsbuxb.ucsb.edu>, <usully@mcl.ucsb.edu> writes:

> 
> In <32qicr$83c@bmerha64.bnr.ca> hsiaoe@bnr.ca (Eric Hsiao) writes:
> 
> 
> >I want to run Mosaic, but as of now, there's no way I can run X-Clients and
> >have them connect to the outside world. 
> While I am not a expert on this, I am preety sure even if their was a 
> firewall and you did have chmod access, you still would not be able to 
> use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
> made for unix, only as a pc or mac app that will only run with a direct 
> connection, i.e if you have slip or ethernet

There is Mosaic for UNIX just ask Sun Microsystems they had it running at 
COMDEX/Toronto. Oh, by the way, I believe, will look into it if I have to, that 
Mosaic was originally written for UNIX, then ported to MS Windows.


Ciao


--
> Craig C. Morley		| No disclaimer! I own the company! :) < 
> 				|                                      < 
> Ex Microsoft and Glad of it!	| The Internet grows at 10% per MONTH! < 
> cmorley@hookup.net		|   There go's the neighbourhood :(    < 

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 18:22:02 GMT
From:      jahansen@halcyon.halcyon.com (john a hansen)
To:        comp.protocols.tcp-ip
Subject:   Re: Tech Report Available

dscially@interserv.com wrote:
: Is your tech report available for a price or is it the graciousness of your generosity that you'll provide it for free?  If it's free then post it somewhere for us to read it at our leisure.  If there is a fee, then, in my humble opinion, pay to adverti
se your services over the appropriate mediums.

: No malice intended.
 
: David
None taken! The only cost is a "Thank You" if you find it useful.
Best Regards
John A Hansen
Networks Northwest Inc.
PO Box 40209
Bellevue Wa 98015
jahansen@networksnw.com

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 20:40:04 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software latency (Was: Speeding up PPP connection..)

In article <BARNETT.94Aug15103121@grymoire.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
>I think the paper is
>
>David Clark, Van Jaconson, John Romkey and Howard Salwen, "An Analysis
>of TCP Processing Overhead" IEEE Communications Magazine pp 22-29 June
>1989.
> ...

1989 was a long time ago. I was refering to something more recent that
I think concerned Van Jacobson's "squashed stack", wherein the protocol
switch and lots of other familiar stuff is short circuited.  I think I
recall references to either public descriptions or a paper by Van Jacobson
in Austrailia.

If you assume that everything remains the same, then it's hard to meander
through sosend and friends, including various dispatch tables without
burning a lot of cycles.  On the other hand, if you take the ideas of
caching, header prediction, and layering violations to their ends, you
go straight from system call to network driver output hook, updating
three and computing one value in the 54 bytes of TCP/IP/Ethernet headers
and skipping the usual TCP, IP, and ARP machinery entirely.

I don't know how he does ACKs, except presumably without fiddling
around with ARP lookups or IP.


Vernon Schryver    vjs@rhyolite.com

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 20:46:49 GMT
From:      pop0002@xs1.simplex.nl (R. Seosahai)
To:        comp.protocols.tcp-ip
Subject:   help needed for mosaic

Hello reader,

I downloaded win32s version 1.15a. I installed it succesfully. There were 
no problems with intsalling it. There is a program that comes with win32s.zip
(A card game). When I start the card game, It starts up, but then when I
click on a menu, the menu highlights but the rest of the menu does not
show. Then my windows becomes unstable so I have to close the application.

I have the same problems with mosaic for win32.
I have windows 3.1 Dutch version. Can anyone help me?


Thanks In Advance,.................. Viper

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

vv       vv  ii  ppppp   eeeee  rrrrr       Rohiet Seosahai, AKA Viper-(M)
 vv     vv   ii  pp  pp  ee     rr  rr	    Schedeldoekshaven 284
  vv   vv    ii  ppppp   eeee   rrrrr	    2511 EW The Hague
   vv vv     ii  pp      ee     rr  rr	    Netherlands
    vvv      ii  pp      eeeee  rr   rr     Student Telematics at polytechnic HU
				   <<>>     
<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>	    Tel. (+31) 70 360 33 43
   <<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>	    
<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>	    e-mail: pop0002@simplex.nl
					    
Some words to remember me by............

'......A politician's most important ability is to foretell 
 what will happen tomorrow and next month and next year - 
 and to explain afterwards why it didn't happen....... '

August '94 Viper :)

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

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 21:00:12 GMT
From:      ebreay@ix.netcom.com (Ed Breay)
To:        comp.protocols.tcp-ip
Subject:   Re: FREE TCP/IP

In <NELSON.94Aug14224655@crynwr.crynwr.com> nelson@crynwr.crynwr.com (Russell Nelson) writes: 

>
>In article <CuIFro.Dtr@adl33cc.adelphi.edu> fischman@auvax1.adelphi.edu writes:
>
>	   Could someone please tell me if there is any sort of 
>   "public domain" TCP/IP software that I can use to communicate
>   with my NetWare v3.11 server, and where I can get it?
>
>Sure.  Get the Crynwr packet driver collection.  In it you'll find a
>bunch of Ethernet drivers.  You'll also find an IPX (in PDIPX103.ZIP)
>that runs over those drivers (it expects to use IEEE_802.3 binding).
>You'll also find SOFTWARE.DOC, which lists free software that runs
>over packet drivers.
>
>And once you outgrow the free stuff, there are a number of commercial
>TCP/IP packages that run over packet drivers.
>
>--
>-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
>Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
>11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
>Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
>

Excuse my obvious lack of knowledge on this subject, but I am needing simple
FTP capability within my small LAN (5 user NetWare 4.0, using ODI drivers),
will this FREE software give me this capability?  And how dificult is it to
install?  Simple as modifying the NET.CFG file???

Thanks in advance for the help.

Ed Breay
....................................................................................

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 09:01:25 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: Port TCP/IP apps to X.25

In article <32qe4c$r2k@crchh81b.bnr.ca> dawkins@bnr.ca (Spencer Dawkins) writes:
>
>There was something in the original post that made me think the poster
>was thinking about modifying TCP to run over X.25. My comment was just
>to call attention to the possibility that these changes would not be
>sufficient -- that the application may have knowledge of IP and IP
>addressing. Looking back, it would have been less confusing if I'd
>said "changing IP to X.25 globally", but I was thinking about the
>addressing aspects of the problem.

  What? The very concept of flooding every PDN in the civilized world
  with ARP storms doesn't have a certain wacky artistic appeal?  >:-)




-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      15 Aug 1994 21:48:58 GMT
From:      rmartin@news.sprintlink.net (Richard Martin)
To:        comp.protocols.tcp-ip
Subject:   mrouted on SS10m51/SUnOS4.1.3_U1B

I am running SunOS4.1.3_U1B on a Sparc10 model 51 and am trying to 
get mrouted to run without success.  I got the kernal patches
for SunOS4.1.3_U1B and installed them but mrouted won't run.  I get:

stealth.sprintlink.net# /usr/etc/mrouted -d 99
debug level 99
mrouted version 2.0
installing le0 (199.0.55.70 on subnet 199.0.55) as vif #0
installing tunnel from 199.0.55.70 to 192.80.214.224 as vif #1
setsockopt DVMRP_ADD_VIF: Can't assign requested address
stealth.sprintlink.net# 

when I try to run it.  Anyone have a clue what might be wrong?

Strangely enough, while mrouted will never work, sd, nv, imm, etc..
will work...but not all the time.

Also, when I try "netstat -M" I get:

stealth.sprintlink.net# netstat -M
mrttable: symbol not in namelist
stealth.sprintlink.net# 

which leads me to believe that something is missing in the kernel.

thanks in advance..

--
Richard Martin
Sprintlink Systems & Services
rmartin@sprintlink.net

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 23:35:22 GMT
From:      bkeeley@ub.com
To:        comp.protocols.tcp-ip
Subject:   Request for TTCP benchmark/test source code

Hello,

I'm looking for TTCP source code, from some anonymous ftp site, to
perform some TCP/IP tests.  Please no flames.  I know it's a well
known tool, but I have never run it and do not know of its location.
Also, is their any other public domain TCP/IP test tools which run
on Solaris 2.3 and/or HP Unix A.90.03.

				Thanks in advance
				Bill K.
				bkeeley@ub.com

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 08:14:52 -0500
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: Port TCP/IP apps to X.25

In article <32oc1o$2i0@pyrnova.mis.pyramid.com>,
Lon Stowell <lstowell@pyrnova.mis.pyramid.com> wrote:
>In article <32nt6a$er@crchh81b.bnr.ca> dawkins@bnr.ca (Spencer Dawkins) writes:
>>

(lots of good comments deleted)

>>Don't think about changing IP to X.121 globally and hoping things will work.
>>TCP knows about IP addresses, you know that, but many applications cache
>>IP addresses (like, FTP). You will probably have to change A LOT. For a 
>>complete list, look at the Firewalls discussions about proxy applications
>>that are needed when firewalls fiddle with IP addresses.
>
>  No, what I meant was that if they administer their own X.25 network
>  and thus have full control of the X.121 addressing in it, they can
>  do what Milnet does and use an algorithm to derive IP from X.121
>  and vice versa. 

There was something in the original post that made me think the poster
was thinking about modifying TCP to run over X.25. My comment was just
to call attention to the possibility that these changes would not be
sufficient -- that the application may have knowledge of IP and IP
addressing. Looking back, it would have been less confusing if I'd
said "changing IP to X.25 globally", but I was thinking about the
addressing aspects of the problem.

Sorry!
-- 
-  Spencer Dawkins	Internet: dawkins@bnr.ca   (214) 684-4827           -
-  "Everything I need to know, I learned reading .signatures on the net"    -

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 00:09:15 GMT
From:      mbeyer@forge.Tandem.com (beyer_mark)
To:        comp.protocols.tcp-ip
Subject:   Re: pacbell isdn


>
>>Anyone have any experience connecting to the internet using ISDN from Pac Bell?
>
>Yup.  I've got one into my house for net access.
>
>I've got the Combinet 160 bridge and I keep the B channels up 24 hours a day 
>if I can.

I also have a Combinet 160 talking to an Ascend hub on our corporate LAN.  It works
fine.  We tested some other equipment but the Combinet/Ascend combination was the
easiest to set up and the price wasn't too bad, either.

Most of the startup problems I had were due to my inexperience with ISDN ("What's a SPID ?").
I suppose the PacBell installer could stand to learn more about data networking
terminology, but we eventually understood each other.

Mark



-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 11:55:51 -0700
From:      cgi@crl.com (Paul Smith)
To:        comp.unix.unixware,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Q: LLC2 interfacing/routing?

Anybody have any idea whether UnixWare's TCP/IP stack can be run over
LLC2 over the LAN to a remote X.25 server??

Even if U.W. does not have this facility that I believe is configured over
the DLPI ethernet driver as another protocol, with IP on top of LLC2, I'm
looking for "simple" how does this work, what can you do with it doc or
literature.

The solution I seek is: an X.25 API (JAXI, SPI or similar) available on a 
host box (U.W., Sun, OSF1) to interface an X.25 server box on the LAN
as if those X.25 services where local to the box 
(sync card, x.25 driver etc).

Any help would be appreciated.  It seems, my confusion of how all this
plugs together has been stuborn for me and others to erradicate....

Thanks, Curt Smith.


-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 12:06:42 -0700
From:      richo@nic.cerf.net (Rich Oldroyd)
To:        comp.protocols.tcp-ip
Subject:   EHLLAPI on OS/2,TCP/IP?




We looking to connect OS/2 PCs running TCP/IP to an AS400. We'd
like to interface to the AS400 using the EHLLAPI API for
5250 terms.  Also would  like to do the same but connect to
a 3270 terminal.  

 --------                                           -------- 
|        |                                         | OS/2 PC |
| AS400  |--- SNA --- "Conversion" ----- TCP/IP ---|  5250   |
|        |             "Software"                  | EHLLAPI |
 --------                                          |  I/F    |
                                                    ---------
Replace the AS400 with 3090 (or other IBM host) and 5250 with 3270. 

                 ANY POINTERS !!!! HELP!!!

It seems OpenConnect has some software that does all this...
but not for the OS/2 platform.  That's our best lead so far.
Any input would be greatly appreciated! (We'll post the
results of the search when complete) 

Rick Rommel
North Communications
310.543.0566

(Using a coworker's account until corp Internet in place.)



-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 01:46:23 GMT
From:      kasey@makesys.com (Kasey Hohenbrink)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   HELP:  Running XFS on 3C509


Question:  Is there a packet driver for the 509 card?  Does it need the 
           ODI stacks to run?

Question:  Is there a shareware/free packet driver that will allow us
           to configure XFS to use a network printer that is on a 
           Unix network running NFS and Solaris?

Question:  Can you supply sample config.?


thanks...


kasey@makesys.com


-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 02:40:09 GMT
From:      engineer@interop.com (Engineer Account)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip
Subject:   Engineer's Interop - March 1995, LasVegas, Call For Papers


                            =====================
                           First Call for Papers
                             -----------------                             
           Engineer's Conference at "NetWorld(R) + INTEROP(R) 94"           
---------------------------------------------------------------------

Interop Company is soliciting technical papers for an Engineer's
Conference to be held as part of the upcoming "NetWorld(R) + INTEROP(R)
95" event, March 27-31 1995, in Las Vegas, Nevada. The Engineer's
Conference, which will run March 29-30,  is a two-day focused event
offering approaches and solutions to practical systems and software
design for networking. All participants in the conference will be
able to attend the "NetWorld(R) + INTEROP(R) 95" exhibition, which will
run from Mar 28-30.

FORMAT

The conference will feature the presentation of original papers
which will have been selected by a review committee. All accepted
papers will be published in Conference Proceedings. Accepted papers
must be presented by original authors during the 2-day conference. 

The Engineer's Conference will concentrate on engineering design
problems in three areas: High Speed Networking, Internetworking,
and Network Management. This conference seeks to bring together
research scholars, engineers, and vendors to address pragamatic
engineering issues in the field of networking and distributed
systems interoperability. It is an excellent forum for Engineers
and Researchers to publish papers on solutions to today's
engineering-related problems.

Papers are solicited in the following areas:

*   High Speed Networking: ATM, Fast Ethernet, SONET, FDDI-II,
    HIPPI, SMDS, Frame Relay, Broadband ISDN, etc.
    
*   Internetworking: Design of Bridges, Routers, and Multiprotocol
    Brouters, Addressing Schemes, Routing Protocols, Application 
    Gateways etc.
    
*   Network Management: Bandwidth utilization, Traffic Trend
    Analysis/Capacity Planning, Automated Trouble Ticket Systems,
    Congestion detection, Network Simulation, SNMP v1 and v2, Security,
    Export considerations for secure systems, Manager-to-manager
    communications, Standardized Testing Suites, Expert Systems,
    Accounting, Distributed/Hierarchical Management architectures, etc.
    
SUBMISSION GUIDELINES

Interested authors are invited to submit an abstract (up to 100
words) clearly describing the problem and the solution offered. All
abstracts will be reviewed and authors are notified for acceptance
or rejection of the abstract. Authors of accepted abstracts must
submit the paper before the last date. These papers are reviewed by
a technical committee for technical merit of the paper before final
acceptance.

Please note the important dates for abstract and paper submission.
All abstracts must contain the authors name, address, telephone
number, Fax number and e-mail address (if available). 

Please send your abstract to:


Interop ( ZD Expo )
303, Vintage Park Dr. Suite 201
Foster City, CA-94404

Attn: Engineer's Conference

or e-mail it (in ASCII or PostScript) to: engineer@zdexpos.com

** E-mail is preferred. **

===================
= Important Dates =
===================
Abstracts due:		Oct. 1, 1994 
Notification to Authors Oct. 15, 1994
Draft paper due: 	Dec. 1, 1994 
Feedback to authors:	Dec. 24, 1995 
Camera ready copy due:	Jan. 10, 1995 
Overhead slides due:	Feb. 15, 1995		

	


-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 02:47:31 GMT
From:      swein@bart.albany.edu (Scott W)
To:        comp.protocols.tcp-ip
Subject:   routing to another gw?

I hope this is the right group.

We have a small lan of linux boxes. We're connected to eachother using
thin-net and we are connected to the net using slip

If machine A with eth0=128.203.1.2 and pl0=128.204.14.249 is connected
to the net, is it possible for machine B with eth0=128.203.2.1 and no
slip connect to connect top the net?

the routing table for machine A looks like

Destination     Gateway         Genmask         Flags MSS    Window Use Iface
127.0.0.1       *               255.255.255.255 UH    1936   0      394 lo
128.203.2.0     *               255.255.255.0   U     1436   0      0  eth0
128.203.1.0     *               255.255.255.0   U     1436   0      6690 eth0
128.203.3.0     *               255.255.255.0   U     1436   0      0 eth0
default         128.204.14.1    *               UG    232    0 16674  sl0

--
Thanks for any help
Scott Weinstein

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 09:19:40
From:      pelkins@uci.edu (Paul Elkins)
To:        comp.protocols.tcp-ip
Subject:   test

This is a test.

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 13:46:02 -0500
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.client-server,comp.protocols.tcp-ip
Subject:   Re: Port TCP/IP apps to X.25

In article <32qnsl$n1p@pyrnova.mis.pyramid.com>,
Lon Stowell <lstowell@pyrnova.mis.pyramid.com> wrote:
>In article <32qe4c$r2k@crchh81b.bnr.ca> dawkins@bnr.ca (Spencer Dawkins) writes:
>>
>>There was something in the original post that made me think the poster
>>was thinking about modifying TCP to run over X.25. My comment was just
>>to call attention to the possibility that these changes would not be
>>sufficient -- that the application may have knowledge of IP and IP
>>addressing. Looking back, it would have been less confusing if I'd
>>said "changing IP to X.25 globally", but I was thinking about the
>>addressing aspects of the problem.
>
>  What? The very concept of flooding every PDN in the civilized world
>  with ARP storms doesn't have a certain wacky artistic appeal?  >:-)
>
 What a GREAT followup!
-- 
-  Spencer Dawkins	Internet: dawkins@bnr.ca   (214) 684-4827           -
-  "Everything I need to know, I learned reading .signatures on the net"    -

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Aug 1994 18:28:51 +0800
From:      peter.lewis@info.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: talk and ntalk protocols: where defined?

In article <rcreager.249.000A9964@sadira.gb.nrao.edu>,
rcreager@sadira.gb.nrao.edu (Ramon E. Creager) wrote:

>Would someone kindly (via e-mail) point me to where these protocols are 
>defined?  I can't find any RFC that does so.

That's because there is no RFC on them, and in fact almost no real
documentation other than the source code (and even finding the source code
for otalk is quite tricky these days).  Probably the reason that there is
no RFC is that the protocol is so confused - these two together also
explains why connecting two machines using Talk is like playing russian
ruletter (except the stakes aren't usually quite so high).  And it's
probably too late to produce a third version of the protocol to fix up all
the mess (although ntalk is at least in theory machine independed :-).

Sorry if I sound bitter, I've written a talk program, it's painful to say
the least.  Find the source and work from there, if you have any specific
questions, you can Email me and I'll be bitter at you some more :-)
   Peter.
-- 
Peter N Lewis <peter.lewis@info.curtin.edu.au> - Macintosh TCP fingerpainter

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 14:47:27 -0400
From:      brad@bach.udel.edu (Brad Cain)
To:        comp.protocols.tcp-ip
Subject:   Routing Software Info Wanted

I'd like to set up a pc as router using two ethernet cards.
The only type of packets it would need to route would be
ip.  I'm also looking for some sort of firewall features too.
I've looked at karlbridge, but it requires the use of SMC
ethernet cards... i'm looking for something that's pretty generic
and pretty cheap (or free).

I know that i can use linux/netbsd/freebsd, and i will if
nothing else pops up.

thanks for any info

-- 
******************************************************************************
brad@bach.udel.edu             * Brad Cain			         N3NAF
cain@ee.udel.edu               * University of Delaware Electrical Engineering
PGP key available via finger   * -Comp. Sci/Signals/Communications/Networking-

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 08:09:55 GMT
From:      hunt@flotsm.ozy.dec.com (Peter Hunt)
To:        comp.protocols.ppp,comp.dcom.isdn,comp.protocols.tcp-ip
Subject:   Local IP addresses when using IP/PPP/ISDN


	I have a question concerning the use of IP addresses when running
IP over PPP over an ISDN network. The idea is that my machine will make
an ISDN call to a remote IP/PPP/ISDN node, which is either standalone
or a gateway to an IP network.

	I have the option of changing my local IP address according to the
host or gateway I connect to. That is, my machine will have different
IP addresses when connected to different IP networks or subnets over the
ISDN network.

	So whenever I connect to gateway A, it knows me as 151.1.1.30,
whereas if I connect to gateway B, it knows me as 160.12.13.30.

	Note that I'm not talking about IP address negotiation. I'm talking
about creating a static association between a local IP address and
a remote subnet accessible across an ISDN network. Connecting to gateway A
will always result in my local IP address being 151.1.1.30.

	My question is: is this a sensible or meaningful thing to do? Will
remote IP/PPP/ISDN gateways typically expect my node to have a particular
address, or an address in their subnet? Or, to ask the reverse question,
will it restrict me if I fix my local IP address so it is the same regardless
of what remote IP subnet I want to call using PPP/ISDN?

	Please reply by mail, rather than to this conference.
--
+-------------------------------+-------------------------------------------+
| Peter Hunt (hunt@ozy.dec.com) |   All young gentle dreams                 |
| Networks Engineering (Aust)   |    drowning in life's grief.              |
| Digital Equipment Corporation |     Can you hang onto me?                 |
+-------------------------------+----- Kate Bush, "Big Stripey Lie", 1993 --+



-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 09:40:21 GMT
From:      dweeks@netcom.com (Don Weeks)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC (Remote Procedure Call) Request for information

Richard Larkin (larkinrp@cs.curtin.edu.au) wrote:
: I would like to know if anyone has any good sites/examples/tutorials on
: programming with RPC. It is for an assignment in my course and I am too
: stingy to buy the RPC book (O'reilly and associates) and was wondering if
: there are any good information sites available that you guys know of.
 
: Much help appreciated in advance thanking you.


: Richard Larkin
: Honours Student
: Computer Science@Curtin University of Technology
: Kent Street, Bentley  6102
: Perth, Western Australia
 
: --
: Richard Larkin
: Honours Student
: Computer Science@Curtin University of Technology
: Kent Street, Bentley  6102
: Perth, Western Australia


I can't remember exactly the site but the examples from the o'reilly book
are on internet. Grab em.


-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 16:59 CDT
From:      hist1a@jane.uh.edu (Lyall, Peter J.)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32rale$i52@nic-nac.CSU.net>, root@dolphin.csudh.edu (Jon Stevens) writes...
>Name withheld upon request (usully@mcl.ucsb.edu) wrote:
>: In <32qicr$83c@bmerha64.bnr.ca> hsiaoe@bnr.ca (Eric Hsiao) writes:
> 
> 
>: >I want to run Mosaic, but as of now, there's no way I can run X-Clients and
>: >have them connect to the outside world. 
>: While I am not a expert on this, I am preety sure even if their was a 
>: firewall and you did have chmod access, you still would not be able to 
>: use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
>: made for unix, only as a pc or mac app that will only run with a direct 
>: connection, i.e if you have slip or ethernet
> 
>Then what is XMosaic? I use it all the time on my SGI and Macintosh 
>Workgroup server running A/UX 3.1!
> 
>-jon stevens
I run a socksified mosaic for Xwindows on my RS^ 6000 using AIX. 
Its easy to say go install socks and you can run u it, but socks]  
code is the spawn of satan tomaster       o master.

jay

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 13:13:52 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Request for TTCP benchmark/test source code

In article <CuLo6z.CIF@pippen.ub.com> bkeeley@ub.com writes:
> I'm looking for TTCP source code, from some anonymous ftp site, to
> perform some TCP/IP tests.  Please no flames.  I know it's a well
> known tool, but I have never run it and do not know of its location.
> Also, is their any other public domain TCP/IP test tools which run
> on Solaris 2.3 and/or HP Unix A.90.03.


I recently ported ttcp to Solaris 2.3. I also fixed up some lint
errors. I'd like to submit the changes to the official keeper of ttcp,
but I don't know who that is.

Solaris 2.3 has two "features" that have to be taken care of to get
networking code in ttcp to work:
	1) "listen(fd,0") doesn't work. 
	   You must use "listen(fd,1)".
	2) you need to specify (sockaddr).sin_family=AF_INET
	   before binding a TCP connection.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 94 19:18:21 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet

In article <CuMu0o.Dxz@ncifcrf.gov>, brownje@ncifcrf.gov (Janet E. Brown) writes:
> In article <328lvf$naf@styx.ibmoto.com> matt@ibmoto.com (Matt Ragan) writes:
>    
>>>Can anyone point me to a version of telnet (source if poss) which 
>>>supports scripting, a bit like comms programs for PCs do?
> 
> [Response concerning Kermit and Expect]
> 
> This is similar to a question I was going to ask: I would like to 
> 'script' an automated Telnet login but through WINDOWS.  We have 
> FTP Corp's PC/TCPIP but any Telnet package would do if it meets 
> our needs.  We'd like to allow a user to click on an icon which
> would automatically connect to an IP host without the user's having 
> to provide a userid or password.  The application we are accessing 
> will not require a password anyway (1/2 our battle won!).  Any 
> shareware available?  Suggestions or experience? 
> 
> Thankee in advance .........
-----------
	Maybe I'm giving away secrets here, Microsoft's secrets fortunately.
Take the case of MS-DOS Kermit running in Windows. One can create an icon
and associate it with a program executable file and the command line which
that program receives when it starts. So for Kermit the command line may
be simply  telnet that.host.over.there,connect  and the normal Kermit
startup file, mskermit.ini, has all the TCP/IP setup canned and ready to
go. If a login process needs to be scripted then that is also straight
forward with MSK. The command line is  telnet that.host.over.there,
take Janelog.tak. The Janelog.tak file has the script which does a
input, output, etc script chatter and ends with a Connect to put the user
in terminal emulation mode.
	Clearly, other comms programs should be able to accomplish the
same goals if they can accept commands both on the invokation line and
from files named on that line.
	Kermit can run on the top of FTP Inc's TNGLASS Int 14h interface,
but specifying a particular host needs to be expressed on the TNGLASS
command line.
        To read about Kermit's commands and capablities you will need a
book, "Using MS-DOS Kermit" by Christine Gianone, 2nd edition (of the
book), Digital Press / Butterworth-Heinemann, 1993, ISBN 1-55558-082-2, 
about US$39 (available in other languages too).
        Joe D.

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 14:13:29 GMT
From:      doug@eng.auburn.edu (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP vs. BOOTP

In article <pjh.3408.2E4C113B@pjh.jvnc.net>, pjh@pjh.jvnc.net (Pete Holsberg) writes:
> (I hope that this is the correct newsgroup.)
> 
> Could someone explain what the difference between RARP and BOOTP is, from the 
> standpoint of dynamic IP addressing?
> 
> Thanks.
> 
> ------------------------------------------------------------------
> Pete Holsberg                   The House On *This* Side Of U.S. 1
> 44 Lopatcong Drive              pjh@mccc.edu
> Ewing, NJ 08638                 pjh@pjh.jvnc.net
> FAX: 609-586-2318
> ------------------------------------------------------------------
>     **** Trenton Computer Festival **** April 22-23, 1995 ****
> ------------------------------------------------------------------

Here's an analogy

RARP = VW beetle - has heat, works
BOOTP = Extended cab pickup - rugged, full of features, extremely useful
        and functional
DHCP = promises to be cadillac - lots of bells and whistles

-------

RARP = I broadcast ethernet MAC address, you give me IP address. end of
       conversation.

BOOTP = I broadcast ethernet MAC address, you give me IP address, default
gateway, nameserver, subnet mask, possibly microcode, maybe a cookie,
and other options. IP address is fixed in a table.

DHCP = like BOOTP - but IP address is dynamic. (in a nutshell)
-- 
____________________________________________________________________________
Doug Hughes					Engineering Network Services
System/Net Admin  				Auburn University
			doug@eng.auburn.edu
"The Light at the end of the tunnel is the headlamp of an oncoming train"

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 14:27:39 GMT
From:      hsiaoe@bnr.ca (Eric Hsiao)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Bypassing internet firewall

Sorry for the crossposting, but I'm not exactly sure what group this post would
fit best in.

Anyway, I want to run Mosaic and be able to connect to WWW sites around the
world, but the problem is, there's this Internet firewall that prevents me
from doing so. The firewall pretty much prevents me from using any X based
clients to connect to anything outside of my own domain. Right now, from my
workstation, I telnet to the gateway/firewall machine. Once on there, I have
a very limited set of commands, like telnet, ftp, etc. From there, I can
go out into the "real world". I cannot run any of my own programs on that
machine as they have not made 'chmod' available to set r-x permissions.
For example, if I compile 'ncftp' and ftp it onto that machine, I can't change
the permissions so I can run it on that machine. Anyway, I'm starting to
digress, so this is my real question:

I want to run Mosaic, but as of now, there's no way I can run X-Clients and
have them connect to the outside world. I was wondering if there's a program
like TERM where I can run one end on my workstation and the other end on a
machine that's not in my domain that would let me run X clients. For example,
I telnet to the gateway, then from there, telnet out to another machine. 
Basically, I need a program like TERM but instead of serial lines, it's
tailored for TELNET connections (two telnet connections in my case...
my WS -> gateway -> outside machine).

Anyone have any insights of programs that do exactly this? Again, I can't
run anything on the gateway machine itself, but I can telnet to it then from
there telnet out to another machine.
-- 
Eric Hsiao     |   ___  __            __        __ | GFX News summer FTP site:
hsiaoe@rpi.edu |  / _  /_  |/   /| / /_  / / / /_  |        ftp.rpi.edu
hsiaoe@bnr.ca  | /__/ /   /|   / |/ /_  /_/_/ __/  |    /pub/misc/gfx-news

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 14:38:47 GMT
From:      brownje@ncifcrf.gov (Janet E. Brown)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet

In article <328lvf$naf@styx.ibmoto.com> matt@ibmoto.com (Matt Ragan) writes:
   
>>Can anyone point me to a version of telnet (source if poss) which 
>>supports scripting, a bit like comms programs for PCs do?

[Response concerning Kermit and Expect]

This is similar to a question I was going to ask: I would like to 
'script' an automated Telnet login but through WINDOWS.  We have 
FTP Corp's PC/TCPIP but any Telnet package would do if it meets 
our needs.  We'd like to allow a user to click on an icon which
would automatically connect to an IP host without the user's having 
to provide a userid or password.  The application we are accessing 
will not require a password anyway (1/2 our battle won!).  Any 
shareware available?  Suggestions or experience? 

Thankee in advance .........

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 14:42:41 GMT
From:      dbrho1@merlion.singnet.com.sg (Deutsche Bank Aktiengesellschaft)
To:        comp.protocols.tcp-ip
Subject:   Protocol analyzer which undestand V.Jacobson TCP header compression

I am looking for a WAN protocol analyzer which is able to understand 
V.Jacobson's TCP/IP header compression (rfc1144).  Is Network General's 
Sniffer able to do this?  Any recommendation will be appreciated.  
Regards, -chandra

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 15:00:04 GMT
From:      geger@starfire.den.mmc.com (George Eger (303) 971-6974)
To:        comp.protocols.tcp-ip
Subject:   Non-blocking accept() and select()

This is actually not a TCP-IP question, but hey, you guys know
everything so here goes.

I am trying to create a non-blocking listening socket to do TCP
connections to.  Normally, after doing the listen(), you need to call
accept() to block waiting for a client's connect request.  I want to
have a task/process in a loop using select() to wake up and do IO.
I want the task to be able to detect a connect request coming in on
the listening socket, while also doing other IO on other file
descriptors.  Can I detect a connect request with select()?  Which
file descriptor mask do I put the listening socket in (the exceptfds)?

Thanks in advance,

GWE

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Integ. Fault Tolerant Avionics  ||   Fax   - (303) - 977 - 1145         ||
||Space Launch Systems            ||   MS T320                            ||
||Martin Marietta Astronautics    ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 16:44:31 GMT
From:      met@cle.ab.com (Mark E. Taylor)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Host-level ethernet redundancy

Our company is developing a redundant industrial control system.  This control-
ler will have an ethernet interface (TCP/IP) to handle some peer-to-peer
communication and communication with VAXs or workstations (data collection,
control panel I/F, etc.).  All system-critical comm. will be handled through
a proprietary, deterministic network, but we still need reliable, highly
available (ie redundant) ethernet communication.  In addition to high availa-
bility, our product needs require the following:

- Redundancy must be hidden from the end-user as much as possible; we don't
  want our users to have to perform a major (or even minor, if possible)
  code rewrite to convert to a redundant system.

- We also need to user to be impacted AS LITTLE AS POSSIBLE by a switchover
  to the backup controller; our marketing types want the comm. delay to be
  less than 2 seconds.  

- Data integrity is important; we HAVE to know that a message is complete.

- The backup ethernet card needs to be minimally active while the primary
  system is operational.  We need to know the the backup card is good when
  we switch over.  This also means that the backup card may have slightly
  different connection information the primary system has.

Being largely ignorant of the inner workings of TCP/IP and ethernet, I went
looking for the two people in our company that I considered most knowledgeable
on the subject.  The gist of what they told me is as follows:

- Swapping IP and physical addresses at switchover isn't a problem, but
  since we're a host and not a router, a simple address swap isn't sufficient.

- 'Ethernet' redundancy isn't a problem (physical, datalink, network layers).
  Things get sticky at the transport layer.  The backup needs all the state
  information that the primary unit had, which is difficult at best.

- Shadowing all the needed TCP level information on the secondary would re-
  quire a non-trivial modification to the TCP code and (even if implemented
  correctly) could hose up performance.

  I'm admittedly pretty fuzzy on the information I was given here.  What I
  was told is DON'T MESS WITH THE TRANSPORT LAYER.

- Redundancy is best implemented at the session layer.  It's comparatively
  easy and more reliable than messing with the lower levels.

  At this level, everything is a transaction.  Once the primary gets a packet,
  it can send it to the backup system (via an ATM-speed data link) before
  receipt of the packet is acknowledged.  If the connection to the primary
  times out, you switch over to the backup's address and continue.

  This method should work fine.  Our company writes the upper-level protocol
  used to communicate with all our ethernet products, so we should be able
  to handle switching to a backup unit at this level with minimal impact to
  an end user or third-party SW developers.  The only problem is network
  timeout.  Network timeouts are 5 - 10 seconds and can't be changed (easily?,
  at all?) so a quick response to a switchover isn't practical.

I'm satisfied with the information my co-workers gave me; it'll do for the
stage of the project that we're in.  However, my boss isn't totally satisfied
with the answers I've been giving him and asked me to get outside information.
So, what I'm asking is given the requirements stated above, are my conclusions
correct?  Is there a way to provide high-performance, HIGHLY reliable host-
level redundancy that is transparent to a user?  My time that I can spend on
reading news will be limited in the near future, so email responses would be
greatly appreciated.  If there are enough replies, I will post a followup.

Thanks in advance,

Mark Taylor   mark.taylor@ab.com

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 23:34:13 -0400
From:      jthomas@pluto.njcc.com (Jay Thomas)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

usully@mcl.ucsb.edu (Name withheld upon request) writes:


>Several people have responded to say that mosaic can in fact be run 
>unix.  The fact still remains that I have yet to see mosaic run on unix, 
>and everyone has told me so far that to run mosaic you need a slip or 
>ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
>with what all these people say, since With all the comments received I 
>would look very foolish.  SOOOOOOO, someone please tell me how I can use 
>mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
>account!!!

You need to be runing an X-windows client on your machine and use xremote 
(a version of PPP for X-window).

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 17:06:17 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking accept() and select()

> Can I detect a connect request with select()?  Which
> file descriptor mask do I put the listening socket in (the exceptfds)?

Yes and no.  When the incoming connection is ready to be accepted,
the listening descriptor becomes readable.

	Rich Stevens

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 23:26:49
From:      mikey@mcs.com (Mike Young)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet

>> In article <328lvf$naf@styx.ibmoto.com> matt@ibmoto.com (Matt Ragan) writes:
>>    
>>>>Can anyone point me to a version of telnet (source if poss) which 
>>>>supports scripting, a bit like comms programs for PCs do?
>> 
You might take a look at comt. It installs a com driver that connects unused 
com ports (say, com6) to sockets. You could then drive it from a scripted, 
Windows based comm program. Procomm and Dynacomm come to mind as possible 
candidates. This roundabout route gives you access to better terminal 
emulation and relatively mature scripting capabilities. It's shareware, but I 
don't know an ftp off-hand.

You might also look at Netmanage's Chameleon. It has a script builder that 
might suit your needs, although I've never tried it. Their telnet also has 
connection profiles that can do the logon stuff for you. If you ask me, I'd 
say ditch the FTP stuff, and try Chameleon.

Mike.


-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 19:15:38 +0000
From:      mmcmullen@gsfcmail.nasa.gov (steve johnson)
To:        comp.security.unix,comp.protocols.tcp-ip,comp.infosystems.www,alt.internet.services
Subject:   Re: Bypassing internet firewall

for those who are interested, i recently attended a conference which
included a presentation by jason ng, one of the software engineers at ncsa
who is working on mosaic.  his presentation is available at
http://www.wais.com:80/SIGNIDR/Proceedings/NCSA/.  in his presentation he
discusssed (very briefly) some future directions for mosaic, some of which
are being worked on now.  one was "secure mosaic".  unfortunately, the
online proceedings are even sparser than his live comments (he had a lot
to cover in ~45 minutes), but you may find it interesting anyway.

most of the general proceedings on copyright issues, knowbots, security,
etc., are available at http://www.wais.com:80/SIGNIDR/.  signidr stands
for special interest group on network information and data retrieval, or
something like that.

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 19:54:39 GMT
From:      sklower@oboe.CS.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: does "routed" support split horizon/poison reverse/triggered updates


In article <CuC50p.1Cu8@austin.ibm.com>,
Anand Teerth Desai <ramana@austin.ibm.com> wrote:
}Does anyone know if BSD4.3/BSD4.4 versions of "routed" command
}(routing protocol daemon) support Split Horizon / Poison Reverse
}or triggered updates ? 

I'm pretty sure it does not.  (I just looked in the master source
tree).  Gated does, however, and I believe IBM is a member of the
gated consortium.  Why not use gated and only compile rip if that's
all you want?

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 20:17:01 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Request for TTCP benchmark/test source code

In article <BARNETT.94Aug16091352@grymoire.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes:

> ...
>I recently ported ttcp to Solaris 2.3. I also fixed up some lint
>errors. I'd like to submit the changes to the official keeper of ttcp,
>but I don't know who that is.
>
>Solaris 2.3 has two "features" that have to be taken care of to get
>networking code in ttcp to work:
>	1) "listen(fd,0") doesn't work. 
>	   You must use "listen(fd,1)".
>	2) you need to specify (sockaddr).sin_family=AF_INET
>	   before binding a TCP connection.


There is no "official keeper of ttcp" in the sense I hope is intended.
I assume there is no expectation for change control over the Silicon
Graphics CDROM's, unlike the guy at the modem vendor who could never
understand why I wouldn't accept blindly his changes to a shipped
configuration script.

Many people have changed ttcp since it was written at BRL as a file
transfer program.  No one really controls it.  There is more than one
varient to be found on the net.

It's been on my list to look at ttcp.c as it is shipped by SGI and
appears on ftp.sgi.com.  When I finally took time today, I found that
Andy Cherenson has already done all that I intended to do.  It already
uses getopt().  It already uses listen(fd,1) for some systems.  I also
wonder if setting sin_family on the incoming socket is a good idea.
The current code has a vague hope of working for a protocol other than
TCP or UDP as determined by the hostname lookup.  Setting
sinme.sin_family=AF_INET would remove that hope.


Vernon Schryver    vjs@rhyolite.com

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 03:21:01 -0400
From:      destiny656@aol.com (Destiny656)
To:        comp.protocols.tcp-ip
Subject:   Inverse multiplexing vs. load sharing

I was wondering whether anyone has experience with T1 inverse multiplexers
(such as IBM 9741, DL3800 or Larscom's Mega-T).  What are the primary
benefits of inverse multiplexing vs. load sharing?  Can individual
sessions be transmitted over multiple paths? For example, if I have two T1
circuits, can a single session go above 1536 kb/s without using a T1
inverse multiplexer?

Also, I have been told that Cisco and Wellfleet will be offering hardware
striping.  Does anyone know whether this is indeed true and if so when it
will be available?

Mandy M.

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 20:46:43 GMT
From:      usully@mcl.ucsb.edu (Name withheld upon request)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In <32qicr$83c@bmerha64.bnr.ca> hsiaoe@bnr.ca (Eric Hsiao) writes:


>I want to run Mosaic, but as of now, there's no way I can run X-Clients and
>have them connect to the outside world. 
While I am not a expert on this, I am preety sure even if their was a 
firewall and you did have chmod access, you still would not be able to 
use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
made for unix, only as a pc or mac app that will only run with a direct 
connection, i.e if you have slip or ethernet


>hsiaoe@rpi.edu |  / _  /_  |/   /| / /_  / / / /_  |        ftp.rpi.edu
>hsiaoe@bnr.ca  | /__/ /   /|   / |/ /_  /_/_/ __/  |    /pub/misc/gfx-news

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 94 21:11:38 GMT
From:      fingerhu@ircam.fr (Michel Fingerhut)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,alt.winsock,comp.os.ms-windows.networking.tcp-ip
Subject:   [Q] Slip routing problem?

Hi world,

I have an Alpha (running OSF/1, a variant of Unix) doing routing between a
PC (Windows 3.1, Cameleon software) connected via a SLIP connection at 38400b
on a serial port and hosts on the Ethernet.  While transfer rates between the
PC and the Alpha are adequate in speed, those between this PC and other (fast)
machines on our LAN are _very_ slow: data seems to flow correctly for a little
while, then it stops for several (long) seconds (10, more) and resumes, and so
on.  The overall transfer rate is abysmally low.

Any suggestions?  Please answer by email, I'll post a summary.

Michael
mf@ircam.fr
-- 
WWW: 	http://www.ircam.fr		tel:	+33 1 44 78 48 53
ftp: 	ftp.ircam.fr			fax:	+33 1 42 77 29 47

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 21:21:50 GMT
From:      root@dolphin.csudh.edu (Jon Stevens)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

Name withheld upon request (usully@mcl.ucsb.edu) wrote:
: In <32qicr$83c@bmerha64.bnr.ca> hsiaoe@bnr.ca (Eric Hsiao) writes:


: >I want to run Mosaic, but as of now, there's no way I can run X-Clients and
: >have them connect to the outside world. 
: While I am not a expert on this, I am preety sure even if their was a 
: firewall and you did have chmod access, you still would not be able to 
: use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
: made for unix, only as a pc or mac app that will only run with a direct 
: connection, i.e if you have slip or ethernet

Then what is XMosaic? I use it all the time on my SGI and Macintosh 
Workgroup server running A/UX 3.1!

-jon stevens

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 21:31:25 GMT
From:      steveTow@rainbow.ecte.uswc.uswest.com
To:        comp.protocols.tcp-ip
Subject:   Andrew File System


I am looking for information on the Andrew File System...RFC's, specifications, 
vendors, etc.  Any pointers to electronic sources?  Any pointers to written 
experiences with AFS?

Thank you...

steveTow

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 21:51:37 GMT
From:      bluejack@voicenet.com (bluejack)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

Name withheld upon request (usully@mcl.ucsb.edu) wrote:
: >I want to run Mosaic, but as of now, there's no way I can run X-Clients and
: >have them connect to the outside world. 
: While I am not a expert on this, I am preety sure even if their was a 
: firewall and you did have chmod access, you still would not be able to 
: use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
: made for unix, only as a pc or mac app that will only run with a direct 
: connection, i.e if you have slip or ethernet

Yeah,
  This guy needs a SLIP connection, rather than an ordinary dialup.
  He should talk to his provider. It isn't a matter of there being
  a firewall, it's just he has the wrong connection.
bluejack
--
         -------------------------------------------------------
              bluejack@omni.voicenet.com    philadelphia,pa
  "I don't care how many levels of reality you posit; as soon as you 
  posit even one it's turtles all the way down." -Nova Spivak. 

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 22:04:55 GMT
From:      rnewman@media.mit.edu (Ron Newman)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32r8jj$flj@ucsbuxb.ucsb.edu>,
Name withheld upon request <usully@mcl.ucsb.edu> wrote:
>While I am not a expert on this, I am preety sure even if their was a 
>firewall and you did have chmod access, you still would not be able to 
>use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
>made for unix, only as a pc or mac app that will only run with a direct 
>connection, i.e if you have slip or ethernet

As someone who uses the X version of Mosaic every day on a Unix
system, I am VERY SURE you're wrong about this.
-- 
Ron Newman		 		MIT Media Laboratory
rnewman@media.mit.edu

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Aug 1994 22:25:31 GMT
From:      tkevans@eplrx7.es.duPont.com (Tim Evans)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

usully@mcl.ucsb.edu (Name withheld upon request) writes:

>In <32qicr$83c@bmerha64.bnr.ca> hsiaoe@bnr.ca (Eric Hsiao) writes:


>>I want to run Mosaic, but as of now, there's no way I can run X-Clients and
>>have them connect to the outside world. 
>While I am not a expert on this, I am preety sure even if their was a 

You certainly aren't.

>firewall and you did have chmod access, you still would not be able to 
>use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
>made for unix, only as a pc or mac app that will only run with a direct 
>connection, i.e if you have slip or ethernet

Mosaic will surely run through a firewall if you can get your 
network folks to set up a "proxy" WWW server inside the firewall.
The one most widely used is from CERN.  As an alternative, there's
something called "SOCKS," which can serve the same purpose of
permitting controlled traffic through a firewall.

-- 
Tim Evans                     |    E.I. du Pont de Nemours & Co.
tkevans@eplrx7.es.dupont.com  |    Experimental Station
(302) 695-9353/8638 (FAX)     |    P.O. Box 80357
EVANSTK AT A1 AT ESVAX        |    Wilmington, Delaware 19880-0357

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 1994 23:43:17 GMT
From:      wetmore@bongos.EBay.Sun.COM. (Brad R. Wetmore)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article i52@nic-nac.CSU.net, root@dolphin.csudh.edu (Jon Stevens) writes:
>Name withheld upon request (usully@mcl.ucsb.edu) wrote:
>: In <32qicr$83c@bmerha64.bnr.ca> hsiaoe@bnr.ca (Eric Hsiao) writes:
>
>
>: >I want to run Mosaic, but as of now, there's no way I can run X-Clients and
>: >have them connect to the outside world. 
>: While I am not a expert on this, I am preety sure even if their was a 
>: firewall and you did have chmod access, you still would not be able to 
>: use mosaic!!! 

Negative, you do need a firewall enabled Mosaic client, such that if an address isn't
local to your firewall, then it will go across the firewall to get the info.
The NCSA Mosaic 2.4 (THE ONE THAT RUNS ON X!) does not do this by default. 
I do not know of one external to Sun, but I use the Sun supplied one all the time.

> I could be mistaken, but I am VERY SURE that mosaic is not 
>: made for unix, only as a pc or mac app that will only run with a direct 
>: connection, i.e if you have slip or ethernet

I'd check my references a little closer before posting!

Brad


---
   /
O /                         Steal here.
 X ----------------------------------------------------------------
O \     Brad Wetmore:                 wetmore@bongos.EBay.Sun.COM
   \    Help!!!  I've been robbed.  Someone stole my .sig, and sold 
        it back at the UCD used .sigstore.


-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 11:47:48 -0700
From:      dmitzel@pollux.usc.edu (Danny Mitzel)
To:        comp.protocols.tcp-ip
Subject:   writev() atomicity on socket write?


I am considering using the writev() system call under SunOS4.1.3/HPUX9.01
to write to a stream socket and have a question on whether this operation
is atomic.  I know that write()'s are typically performed using a loop
similar to:
    while (nbytes > 0) {
	nwritten = write(fd, ptr, nbytes);
        nbytes -= nwritten;
	ptr += nwritten;
    }
because the write() call is not guaranteed to atomically write the entire
'nbytes' in one call.  this loop would become more complex using multiple
buffers and writev() gather.

so, my question is:  is the writev() guaranteed to atomically write 'nbytes'
or do I need to write a while loop similar to the one above to walk across
the multiple buffers?

thanks for any info!
danny (mitzel@catarina.usc.edu)

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 00:34:41 GMT
From:      caa@unify.com (Chris Anderson)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

According to Name withheld upon request <usully@mcl.ucsb.edu>:
> In <32qicr$83c@bmerha64.bnr.ca> hsiaoe@bnr.ca (Eric Hsiao) writes:
> 
> 
> >I want to run Mosaic, but as of now, there's no way I can run X-Clients and
> >have them connect to the outside world. 
> While I am not a expert on this, I am preety sure even if their was a 
> firewall and you did have chmod access, you still would not be able to 
> use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
> made for unix, only as a pc or mac app that will only run with a direct 
> connection, i.e if you have slip or ethernet

Well, you're VERY WRONG.  Mosaic is available for X-Windows.

As for going through the firewall, presumably it's there for a reason. 
Instead of bypassing it, why don't you talk to your sysadmins and see if
they will install one of the proxy servers?

Chris

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 12:44:30 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32s0fl$a5a@pluto.njcc.com> jthomas@pluto.njcc.com (Jay Thomas) writes:
>
>You need to be runing an X-windows client on your machine and use xremote 
>(a version of PPP for X-window).

   No you don't.  You just need X11 on your unix box so it can run
   Mosaic.  How you as a user would access that depends entirely
   on how your specific display is attached to the unix system.

   You could run it right from the console, from an x-terminal on a
   LAN, from an X-terminal over X-Remote, from a PC on the LAN, from a
   PC remoted via SLIP or PPP or whatever.  



-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 01:23:43 GMT
From:      usully@mcl.ucsb.edu (Name withheld upon request)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall


Several people have responded to say that mosaic can in fact be run 
unix.  The fact still remains that I have yet to see mosaic run on unix, 
and everyone has told me so far that to run mosaic you need a slip or 
ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
with what all these people say, since With all the comments received I 
would look very foolish.  SOOOOOOO, someone please tell me how I can use 
mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
account!!!

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 01:50:41 GMT
From:      sarr@citi.umich.edu (Sarr J. Blumson)
To:        comp.protocols.tcp-ip
Subject:   Re: Andrew File System

AFS is a commercial product sold by Transarc (I think that's
still there name, they were bought by IBM this morning).  Try
{sales, info}@transarc.com.

There is also a newsgroup (with a FAQ), alt.filesystems.afs.

PS. steveTow@rainbow.ecte.uswc.uswest.com gets a "host unknown".
-- 
--------
Sarr Blumson                         sarr@citi.umich.edu
voice: +1 313 764 0253               home: +1 313 665 9591
CITI, University of Michigan, 519 W William, Ann Arbor, MI 48103-4943

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 02:03:23 GMT
From:      cwctancl@leonis.nus.sg (Mr Tan Cheng Lin)
To:        comp.protocols.tcp-ip
Subject:   wanted:IPX Router Source Code in 'C'


Hi,
	Anyone knows where can I get or purchased IPX router source
code in 'C'.


Tan Cheng Lin
cwctancl@leonis.nus.sg

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 14:11:08 -0700
From:      stevel@crl.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   SMTP DNS Screwup?

I know I'm doing something wrong in my code, probably missing the trailing
dot for a FQDN but I'm not sure exactly where in the process it should be
done.  I've looked at sendmail but end up lost...

Everything has worked fine in my SMTP up to now, until I tried to send a
message to bmd.ucl.ac.be and weird things happen.  If I use nslookup on
the MX records for bmd.ucl.ac.be. I find lewsun.md.ucl.ac.be however,
if I use nslookup on bmd.ucl.ac.be (no dot) the reply says 
netcomsv.netcom.com and the lookup hostname is returned as bmd.ucl.ac.be.com

I'm fairly certain I need to have that final dot somewhere in the process
but am not real sure at what point.  I lookup CNAME, MX, then A records.
I don't believe it should be in the mail header.  Should I make sure
the address ends in a dot before CNAME or just before MX lookup?  I have
TCP/IP Ill. V1 and DNS&BIND but just can't quite be sure of the answer.

-stevel@crl.com


-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 09:23:10 -0400
From:      smartin@cpisun3.navsea.navy.mil (Sam Martin)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet


WinQVT offers a rudmintary script, along with an auto_start feature which
I use to start an application. Rudimentary, I meant! and rudimentary it is!
Luck, Sam

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 03:07:27 GMT
From:      ralphs@halcyon.halcyon.com (Ralph Sims)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

usully@mcl.ucsb.edu (Name withheld upon request) writes:

>Several people have responded to say that mosaic can in fact be run 
>unix.  The fact still remains that I have yet to see mosaic run on unix, 
>and everyone has told me so far that to run mosaic you need a slip or 
>ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
>with what all these people say, since With all the comments received I 
>would look very foolish.  SOOOOOOO, someone please tell me how I can use 
>mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
>account!!!

I have a unix machine directly connected to the Internet.  On that
machine I run mosaic in an X-window environment.  I happen to connect
that machine to the Internet with a SLIP account, but it would make
no difference if it were connected to the Internet with a T-3 line--
the principle is the same.  You can also run Linux on your home
machine (certain hardware issues, etc. aside), and use 'term' on
both your unix host and your home machine to emulate a slip
connection and run a term version of mosaic over that link
(again, provided your host will support term, either administratively or
through the operating system, or both).

Personal;ly, I'd ask your unix machine's admin staff about
your alternatives.


-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 03:38:34 GMT
From:      mtpins@icaen.uiowa.edu (Michael T Pins)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

rnewman@media.mit.edu (Ron Newman) writes:

>In article <32r8jj$flj@ucsbuxb.ucsb.edu>,
>Name withheld upon request <usully@mcl.ucsb.edu> wrote:
>>While I am not a expert on this, I am preety sure even if their was a 
>>firewall and you did have chmod access, you still would not be able to 
>>use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
>>made for unix, only as a pc or mac app that will only run with a direct 
>>connection, i.e if you have slip or ethernet
 
>As someone who uses the X version of Mosaic every day on a Unix
>system, I am VERY SURE you're wrong about this.

As far as I know, Mosaic was created for unix boxes with an X interface and
was only ported to pcclones and macs at a later date.  Oh, and Mosaic works
quite well on an Amiga via DNet, no slip/ethernet/etc needed, so he's
0-for-2.
One of these days these kids will learn that life doesn't really revolve
around pcclones and macs, but I wouldn't hold my breath.

-- 
*****************************************************************************
* Michael Pins                     |    Internet: mtpins@icaen.uiowa.edu    *
* ISCA's Amiga & Unix Librarian    |        #include <std.disclaimer>       *
*****************************************************************************

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 12:09:09 -0500
From:      tjb@Starbase.NeoSoft.COM (Timothy J. Bogart)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32tai9$clk@news.panix.com>, Wayne Berke <berke@panix.com> wrote:
>root@dolphin.csudh.edu (Jon Stevens) writes:
>
>>You are NOW adding that you would like to do it without slip or ppp...you 
>>did not say that before...without slip or ppp or "direct ethernet" you 
>>can't run any form of Mosaic (Mac,PC,X)...but you can easily run lynx on 
>>a unix host. Yes, you DID look foolish. Also, JUST because you have not 
>>SEEN it run on Unix does not mean that it exists. In fact....I would say 
>>that XMosaic is the application that the people at NCSA update first.
>
>Am I missing something?  What does the PPP or SLIP have to do with anything?
>Won't any form of Internet connection do?  Granted without an Internet
>connection you wouldn't be able to run Mosaic, but isn't that true for
>lynx also?
[snip]

This all sounds like the standard problem with someone buying 
Internet access.  You buy your basic access which is to dial
up and use character mode terminal emulators.  You run Lynx on
the unix box you log into at your provider.  The next step
is to have folks tell you that if you are running Windows we
can set you up with a PPP or SLIP access and you can run
Mosaic!  I have run into more than one person who gets real
confused about the differences between these two setups - it
has taken a white board and some time to get the fundametals
across to even an experienced client/server programmer.

After all, you could say you have an ethernet connection in
either case, right?  It is only the _form_ of the connection
that is so different.  8-)





-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 03:55:44 GMT
From:      root@dolphin.csudh.edu (Jon Stevens)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

Name withheld upon request (usully@mcl.ucsb.edu) wrote:

: Several people have responded to say that mosaic can in fact be run 
: unix.  The fact still remains that I have yet to see mosaic run on unix, 
: and everyone has told me so far that to run mosaic you need a slip or 
: ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
: with what all these people say, since With all the comments received I 
: would look very foolish.  SOOOOOOO, someone please tell me how I can use 
: mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
: account!!!

In your original message you wrote:
While I am not a expert on this, I am preety sure even if their was a
firewall and you did have chmod access, you still would not be able to
use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not
made for unix, only as a pc or mac app that will only run with a direct
connection, i.e if you have slip or ethernet
-------------

You are NOW adding that you would like to do it without slip or ppp...you 
did not say that before...without slip or ppp or "direct ethernet" you 
can't run any form of Mosaic (Mac,PC,X)...but you can easily run lynx on 
a unix host. Yes, you DID look foolish. Also, JUST because you have not 
SEEN it run on Unix does not mean that it exists. In fact....I would say 
that XMosaic is the application that the people at NCSA update first.

-Jon Stevens
root@dolphin.csudh.edu
http://dolphin.csudh.edu/



-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 16:17:17 -0700
From:      llmccall@ccnet.com (Lindsay McCall)
To:        comp.protocols.tcp-ip
Subject:   How to request a block of class-C addresses?

I am unclear what magic words to use on the Internic request form 
that will get me a nice, consecutive block of about eight class-C 
addresses.  Is there a separate form I need to use?  The form I submitted 
got me one class-C group although I asked for more than one.  
Incidentally, is there a way to return these addresses into the pool?  
Maybe it's ignorance or lack of imagination, but one isolated group of 
addresses doesn't seem much use if I really need more, and if they were 
grouped together, it seems like I could better control my need to apply 
routers in strategic places.  Can anybody help or direct me to a faq, RFC 
etc that's on point?

Thanks...

Yours in TCP/IP unsophistication,

Lindsay McCall
Morrison & Foerster

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 05:00:44 GMT
From:      mbarkah@slate.mines.colorado.edu (Ade Barkah)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

Dave Horsfall (dave@eram.esi.com.au) wrote:
:     scum@pcthree.com (Steve Monroe) writes:
 
: | That's if you can find it to run on your Dell 2.2.  PPP on PC/Unix
: | seems to be largely ignored by commercial and free markets.
 
: Unless I've misinterpreted your remark, that's news to me.  PPP is
: available for commercial BSD/386 and free Linux.  So is SLIP, but I
: don't use it.  There is also a free version that runs on Ultrix, Net/BSD,
: SunOS, etc etc.

Perhaps, without trying to guess the original author's mind,
that should have read:

  "...largely ignored by System V markets."


-Ade Barkah

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 17:36:48 -0700
From:      cbarnett@crl.com (Charles R. Barnett)
To:        comp.protocols.tcp-ip
Subject:   Tandem TCP/IP - Any users?

Is anyone currently using Tandem Computer's TCP/IP implementation and 
would be willing to answer a few conceptual level questions?  (i.e., what 
are the strengths, weaknesses, and security concerns you've encountered).

Please mail to:  cbarnett@crl.com

Sufficient responses will be summarized and posted.

Thanks.

cbarnett@crl.com
Charles Barnett


-- 
Charles R. Barnett
cbarnett@crl.com


-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 06:48:06 GMT
From:      michaelv@MindBender.HeadCandy.com (Michael L. VanLoon)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

In article <1994Aug15.122022.21200@pcthree.com> scum@pcthree.com (Steve Monroe) writes:

   That's if you can find it to run on your Dell 2.2.  PPP on PC/Unix
   seems to be largely ignored by commercial and free markets.

Commercial markets, yes.  But how do you figure it's ignored by free
markets?  NetBSD and FreeBSD both "ship" with PPP as part of the
kernel sources -- just build a kernel with a PPP interface and you're
good to go.

I've heard Linux also comes with or has easily available PPP (can't
speak authoritatively on Linux since I don't run it.

And, I also have to take to task "PC/Unix".  The freeware PC/unix
"market" is where PPP is the most alive, from what I've noticed.  The
big commercial workstation Unix companies (DEC, Sun, HP, ...) haven't
done much to support PPP that I've noticed.

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Michael L. VanLoon     michaelv@HeadCandy.com     michaelv@iastate.edu
  Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc.
     Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532
               In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 14:18:57 -0400
From:      tom@aisun.aiinet.com (Tom Herbert)
To:        comp.protocols.tcp-ip
Subject:   Re: Any vendors of TCP (without IP)?

In article <1994Aug10.124600.25015@brtph560.bnr.ca> bhaskar@brtph181.bnr.ca (Shaji Bhaskar) writes:
>
>I don't understand why you say TCP is linked to IP.  RFC 793 says that
>TCP is not tied to any particular network layer, and Douglas Comer in
>"Internetworking with TCP/IP" makes the same statement.  Sure, RFC 1122
>links TCP and IP, but that document is meant for users of the TCP/IP
>protocol suite as opposed to just TCP.
>

I see some problems in trying to do TCP without IP encapsulation in that
TCP connections and the protocol itself are linked to the IP addresses
of the communicating hosts.

RFC 793 says that the IP source and destination addresses are used
in the calculation of the TCP checksum.  So unless you're going depart
from the TCP spec, you'll need to provide some kind of addresses (possibly
bogus) to do this calculation.


If you choose to hack the code, I would suggest providing a very thin
layer of IP that does nothing more than put in a source and dest addresses,
total length, and calculates a header checksum.  The rest of the fields of 
the IP header can be filled in with some static values.  This is routable,
has low processing overhead, and should conform to the IP spec.

If you choose not to encapsulate TCP in IP packets, you may want to at
least have some sort of mapping between IP addresses and physical addresses,
this might allow TCP functions and applications to still deal with IP
addresses.



Tom Herbert
Applied Innovation Inc.
Dublin, OH 43017

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 17:58:10 -0500
From:      tjb@Starbase.NeoSoft.COM (Timothy J. Bogart)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <ellis.777145710@gmi.edu>,
R. Stewart Ellis <ellis@nova.gmi.edu> wrote:
>root@dolphin.csudh.edu (Jon Stevens) writes:
>
> >Name withheld upon request (usully@mcl.ucsb.edu) wrote:
 
> >: Several people have responded to say that mosaic can in fact be run 
> >: unix.  The fact still remains that I have yet to see mosaic run on unix, 
> >: and everyone has told me so far that to run mosaic you need a slip or 
> >: ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
> >: with what all these people say, since With all the comments received I 
> >: would look very foolish.  SOOOOOOO, someone please tell me how I can use 
> >: mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
> >: account!!!
 
> >In your original message you wrote:
> >While I am not a expert on this, I am preety sure even if their was a
> >firewall and you did have chmod access, you still would not be able to
> >use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not
> >made for unix, only as a pc or mac app that will only run with a direct
> >connection, i.e if you have slip or ethernet
> >-------------
 
> >You are NOW adding that you would like to do it without slip or ppp...you 
> >did not say that before...without slip or ppp or "direct ethernet" you 
> >can't run any form of Mosaic (Mac,PC,X)...but you can easily run lynx on 
>Ddddiiinnngggg!!! wrong answer.  I run Mosaic all the time without any of
>the above using a term socket connection between a Sun at home and one at
>work.  PC's can run X at home under DOS or windoze and connect with several
>products of the ilk of Xremote.

All of which take the form of supplying slip or ppp capabilities.  As 
to be distinguished from running a simple vt100 or ansi terminal
emulator.  The first makes your PC at home a node on the net and the latter
makes your box a dumb character terminal.  Under the latter your run
lynx, as the man said.

> >a unix host. Yes, you DID look foolish. Also, JUST because you have not 
> >SEEN it run on Unix does not mean that it exists. In fact....I would say 
> >that XMosaic is the application that the people at NCSA update first.
>
>Now who looks foolish!

Indeed.

> >-Jon Stevens
> >root@dolphin.csudh.edu
> >http://dolphin.csudh.edu/
>
>
>-- 
>  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765   ___________________
>  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.    /   _____  ______ 
>  Flint, MI 48504      ellis@nova.gmi.edu               /        / /  /  / /
>  Gopher,chimera,nn,tin,jove,modems, free code is best!/________/ /  /  / /



-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 09:40:40 GMT
From:      ivanoff@netcom.com (Alex Ivanoff)
To:        comp.protocols.tcp-ip
Subject:   Chameleon slip setup ???

I am trying to set up a SLIP account using Internet Chameleon v4.0.  
When connecting to a host via the CUSTOM application, I get the following 
dialog:
	ATDT 687 3945
	Connect 14400/REL
	Welcome to ElectriCity
	
	User access verification
	Username: ivanoff
	ivanoff
	Password: ************
 
After this dialog the connection is maintained, but none of the 
applications function.  I suspect that the script in c:\netmanage\slip.ini
is not executing properly.  

	[ElectriCiti.com]
	SCRIPT=name: $u$r word: $p$r
	TYPE=SLIP

I have verified my modems operation, and to the best of my knowledge, all 
the pertinent network information is correct.  Is the above script 
complete considering that my host dynamically assigns I.P. addresses
upon connecting.
Any help will be GREATLY appreciated!
Alex Ivanoff 
-- 
                                           Ivanoff@netcom.com

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 09:57:00 +0000
From:      aelman@cs.stanford.edu (Adam Elman)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32roqv$kaa@ucsbuxb.ucsb.edu>, usully@mcl.ucsb.edu (Name
withheld upon request) wrote:

> Several people have responded to say that mosaic can in fact be run 
> unix.  The fact still remains that I have yet to see mosaic run on unix, 
> and everyone has told me so far that to run mosaic you need a slip or 
> ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
> with what all these people say, since With all the comments received I 
> would look very foolish.  SOOOOOOO, someone please tell me how I can use 
> mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
> account!!!

Mosaic for UNIX is an X windows program, which means you must be using a
graphical workstation or terminal to use it.

If you are using a text-only terminal, which it sounds like you are, you
can't use Mosaic.

Remember, UNIX doesn't necessarily mean text-only terminal...

Adam

-- 
Adam Elman             | WWW: http://rescomp.stanford.edu/~elmanad/
aelman@cs.stanford.edu | Finger me or check out my Web page for PGP key!!!
--------------------------------------------------------------------------
"Sometimes I lie awake at night and ask 'Where did I go wrong?'  Then a voice answers 'This will take some time to explain...'" -- Peanuts

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 12:09:37 GMT
From:      larry@gator.rn.com (Larry D Snyder)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

michaelv@MindBender.HeadCandy.com (Michael L. VanLoon) writes:

>In article <1994Aug15.122022.21200@pcthree.com> scum@pcthree.com (Steve Monroe) writes:
 
>   That's if you can find it to run on your Dell 2.2.  PPP on PC/Unix
>   seems to be largely ignored by commercial and free markets.
 
>Commercial markets, yes.  But how do you figure it's ignored by free
>markets?  NetBSD and FreeBSD both "ship" with PPP as part of the
>kernel sources -- just build a kernel with a PPP interface and you're
>good to go.

BSD386 1.1 comes with both PPP and SLIP - all set to run out of
the box - and is a complete OS for $500.  Complete source is available
as well - and is well supported via not only the net, but by live 
people on a 1-800 number..

-- 
Larry Snyder
larry@gator.rn.com

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 12:26:28 GMT
From:      chris@Minsk.docs.uu.se (Christian Bartholdsson )
To:        comp.security.unix,comp.protocols.tcp-ip,comp.infosystems.www,alt.internet.services
Subject:   Re: Bypassing internet firewall

mmcmullen@gsfcmail.nasa.gov (steve johnson) writes:

>most of the general proceedings on copyright issues, knowbots, security,
>etc., are available at http://www.wais.com:80/SIGNIDR/.  signidr stands
>for special interest group on network information and data retrieval, or
>something like that.

Typical.  The one I'm interested in (PC1, copyright issues) is not 
available.  :-(

- chris@minsk.docs.uu.se            <http://www.update.uu.se/~chris/>

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 13:03:49 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Request for TTCP benchmark/test source code

In article <Cun9oE.7o9@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
> It's been on my list to look at ttcp.c as it is shipped by SGI and
> appears on ftp.sgi.com.  When I finally took time today, I found that
> Andy Cherenson has already done all that I intended to do.  It already
> uses getopt().  It already uses listen(fd,1) for some systems.  I also
> wonder if setting sin_family on the incoming socket is a good idea.
> The current code has a vague hope of working for a protocol other than
> TCP or UDP as determined by the hostname lookup.  Setting
> sinme.sin_family=AF_INET would remove that hope.


That's a point I hadn't considered. I could add a #ifdef around that
line if people think it's a good idea.

I added several casts to the code, which makes Sun's compiler happy.
I also made Sun's lint happier too. I don't think the changes I made
will affect the porting issues to any platform, with the exception
Vernon mentioned above. However, I am not positive about this.

The context diff is ~500 lines, and the source is ~850 lines. GE
doesn't have an anonymous FTP site, so I am looking for someone to
make a copy available. It seems a waste to make these changes and not
have a place or person to send them too.


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

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 13:43:56 GMT
From:      paf@staff.nada.kth.se (Patrik Faltstrom)
To:        comp.protocols.tcp-ip,comp.infosystems
Subject:   Re: What ever happened to whois++?

In article <1994Aug15.142528.7477@ivax> imhw400@indyvax.iupui.edu (Mark H. Wood) writes:
>In article <32kv76$hqo@news.kth.se>, paf@staff.nada.kth.se (Patrik Faltstrom) writes:
>> I agree that it's gopher together with for example ph which is what
>> is used today, but what all services, X.500, whois and ph lacks
>> is a mechanism for automatic requerying a second server if the first
>> one doesn't have the record you are searching for. Whois++ does
>> have this indexing mechanism and that is why I think that the
>> Whois++ protocol will be used.
>
>Hmmm, I thought that the X.500 DUA was supposed to continue rooting through the
>DIT until it either finds a hit or gets a definitive no-answer?  Why is all
>that replication stuff in there otherwise?

You are correct, but there is no information in X.500 of how to find the
correct server which contains the record you are looking for.
There is no indexing information moved between different X.500
databases, so you actually have to query all X.500 databases that
exists (that you know about).

When using Whois++, you do get "pointers" or "servers-to-ask"
responses to your query which only points towards servers
that actually do have the record you are looking for.

	paf

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 00:48:02 -0600
From:      thu@nyx10.cs.du.edu (Timothy Hu)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32qicr$83c@bmerha64.bnr.ca>, Eric Hsiao <hsiaoe@bnr.ca> wrote:
>Sorry for the crossposting, but I'm not exactly sure what group this post would
>fit best in.
>
>Anyway, I want to run Mosaic and be able to connect to WWW sites around the
>world, but the problem is, there's this Internet firewall that prevents me
>from doing so. The firewall pretty much prevents me from using any X based
>clients to connect to anything outside of my own domain. Right now, from my
>workstation, I telnet to the gateway/firewall machine. Once on there, I have
>a very limited set of commands, like telnet, ftp, etc. From there, I can
>go out into the "real world". I cannot run any of my own programs on that
>machine as they have not made 'chmod' available to set r-x permissions.
>For example, if I compile 'ncftp' and ftp it onto that machine, I can't change
>the permissions so I can run it on that machine. Anyway, I'm starting to
>digress, so this is my real question:
>
>I want to run Mosaic, but as of now, there's no way I can run X-Clients and
>have them connect to the outside world. I was wondering if there's a program
>like TERM where I can run one end on my workstation and the other end on a
>machine that's not in my domain that would let me run X clients. For example,
>I telnet to the gateway, then from there, telnet out to another machine. 
>Basically, I need a program like TERM but instead of serial lines, it's
>tailored for TELNET connections (two telnet connections in my case...
>my WS -> gateway -> outside machine).
>
>Anyone have any insights of programs that do exactly this? Again, I can't
>run anything on the gateway machine itself, but I can telnet to it then from
>there telnet out to another machine.
>-- 
>Eric Hsiao     |   ___  __            __        __ | GFX News summer FTP site:
>hsiaoe@rpi.edu |  / _  /_  |/   /| / /_  / / / /_  |        ftp.rpi.edu
>hsiaoe@bnr.ca  | /__/ /   /|   / |/ /_  /_/_/ __/  |    /pub/misc/gfx-news

Yes, you can still use TERM (I use term118) over a telnet connection. use
the latest version of kermit (I believe it's 5A(190) ).

I use it all the time over telnet connections....

Cheers,
Tim

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 15:32:25 GMT
From:      berke@panix.com (Wayne Berke)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

root@dolphin.csudh.edu (Jon Stevens) writes:

>You are NOW adding that you would like to do it without slip or ppp...you 
>did not say that before...without slip or ppp or "direct ethernet" you 
>can't run any form of Mosaic (Mac,PC,X)...but you can easily run lynx on 
>a unix host. Yes, you DID look foolish. Also, JUST because you have not 
>SEEN it run on Unix does not mean that it exists. In fact....I would say 
>that XMosaic is the application that the people at NCSA update first.

Am I missing something?  What does the PPP or SLIP have to do with anything?
Won't any form of Internet connection do?  Granted without an Internet
connection you wouldn't be able to run Mosaic, but isn't that true for
lynx also?

>-Jon Stevens
>root@dolphin.csudh.edu
>http://dolphin.csudh.edu/


--
Wayne Berke
berke@panix.com

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 15:34:22 GMT
From:      nagendra@csa.bu.edu (nagendra mishr)
To:        comp.protocols.tcp-ip
Subject:   location server design.....


I have a server which keeps track of the location for various
sub-servers and I have come across a problem and am wondering what
kinds of solutions are apropriate...

The problem is that any of the sub-servers may die and the next
request for the service should not include the address of that dead
sub-server..  Basically, is there a way to detech that there is
noone-listening on a port on some machine?

a sub-server starts up by sending a UDP packet to the location server
and the location server in turn assigns an id to the sub-service and
returns that.  The next time a request for a service comes in the
location server returns the addresses of all the services it knows
about.

any help appreciated

thanks
Nagendra
nagendra.csa.bu.edu


-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 16:22:38 GMT
From:      caa@unify.com (Chris Anderson)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

According to Name withheld upon request <usully@mcl.ucsb.edu>:
> 
> Several people have responded to say that mosaic can in fact be run 
> unix.  The fact still remains that I have yet to see mosaic run on unix, 
> and everyone has told me so far that to run mosaic you need a slip or 
> ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
> with what all these people say, since With all the comments received I 
> would look very foolish.  SOOOOOOO, someone please tell me how I can use 
> mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
> account!!!

Because you haven't seen it, doesn't mean that it doesn't exist.

As far as running Xmosaic, if you have X windows and the motif libraries, 
then you can run Xmosaic.  The fact that you can connect with Lynx means
that you have network access of some sort to the internet, whether it be
via slip, ppp, ethernet, firewall, etc.

You need to talk to your sysadmins about this.

Chris

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 16:34:40 GMT
From:      tcora@pica.army.mil (Tom Coradeschi)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

usully@mcl.ucsb.edu (Name withheld upon request) wrote:
> Several people have responded to say that mosaic can in fact be run 
> unix.  The fact still remains that I have yet to see mosaic run on unix, 
> and everyone has told me so far that to run mosaic you need a slip or 
> ethernet account.

Well then "everyone" is wrong.

> ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
> with what all these people say, since With all the comments received I 
> would look very foolish.  SOOOOOOO, someone please tell me how I can use 
> mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
> account!!!

Get XMosaic. Install it. Run it. (Hint: ftp://ftp.ncsa.uiuc.edu/Web/)

                 tom coradeschi <+> tcora@pica.army.mil

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 13:31:35 +0200
From:      szymon@galaxy.uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP vs. BOOTP

Doug Hughes (doug@eng.auburn.edu) wrote:

: RARP = I broadcast ethernet MAC address, you give me IP address. end of
:        conversation.
 
: BOOTP = I broadcast ethernet MAC address, you give me IP address, default
: gateway, nameserver, subnet mask, possibly microcode, maybe a cookie,
: and other options. IP address is fixed in a table.

This misses one IMHO important point:
RARP request is an Ethernet broadcast. It is not an IP packet - well, it
is RARP packet :-) Thus it cannot be routed.
BOOTP request is an UDP packet - ie. it is IP packet and thus can be forwarded
if your router has an option of passing UDP broadcasts (CISCO has, for 
example). For this reason, RARP is suitable for simple LANs, but if you have
a more complex topology, BOOTP is better.
There is nothing to stop you from writing a daemon that will assign addresses
dynamically to RARP requests. Modyfing a standard rarpd to do so should be
a matter of 2-3 hours.
--
                           Szymon Sokol -- Network Manager
U     U  M     M  M     M  University of Mining and Metallurgy, Computer Center
U     U  MM   MM  MM   MM  ave. Mickiewicza 30, 30-059 Krakow, POLAND
U     U  M M M M  M M M M  TEL. +48 12 338100 EXT. 2885  FAX +48 12 338907
 UUUUU   M  M  M  M  M  M  finger szymon@galaxy.uci.agh.edu.pl for PGP key
                           WWW page: http://www.uci.agh.edu.pl/~szymon/

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 17:07:38 GMT
From:      shark@netcom.com (Stefan Sharkansky)
To:        comp.protocols.tcp-ip
Subject:   Re: Non-blocking accept() and select()

In article <1994Aug16.150004.14087@den.mmc.com> geger@starfire.den.mmc.com (George Eger (303) 971-6974) writes:

>I want the task to be able to detect a connect request coming in on
>the listening socket, while also doing other IO on other file
>descriptors.  Can I detect a connect request with select()?  Which
>file descriptor mask do I put the listening socket in (the exceptfds)?

You can use select() to detect an incoming connection request if you put
the listening socket in the readfds.

Stefan

--

Stefan Sharkansky
Prospero Systems Research, Inc.
USMAIL	520 Frederick St. Box 19, San Francisco, CA 94117
VOICE	(415) 731-8114		FAX  (415) 731-3395
E-MAIL	shark@netcom.COM


-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 17:13:55 GMT
From:      jjb@jagware.bcc.com (J.J.Bailey)
To:        comp.infosystems.www,comp.protocols.tcp-ip,,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32s0fl$a5a@pluto.njcc.com> jthomas@pluto.njcc.com (Jay Thomas) writes:
>usully@mcl.ucsb.edu (Name withheld upon request) writes:
>
>
>>Several people have responded to say that mosaic can in fact be run 
>>unix.  The fact still remains that I have yet to see mosaic run on unix, 
>>and everyone has told me so far that to run mosaic you need a slip or 
>>ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
>>with what all these people say, since With all the comments received I 
>>would look very foolish.  SOOOOOOO, someone please tell me how I can use 
>>mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
>>account!!!
>
>You need to be runing an X-windows client on your machine and use xremote 
>(a version of PPP for X-window).

You don't need xremote.

-- 
J.J.Bailey
Consultant
jjb@jagware.bcc.com

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 94 17:41:38 GMT
From:      ellis@nova.gmi.edu (R. Stewart Ellis)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

usully@mcl.ucsb.edu (Name withheld upon request) writes:


 >Several people have responded to say that mosaic can in fact be run 
 >unix.  The fact still remains that I have yet to see mosaic run on unix, 
 >and everyone has told me so far that to run mosaic you need a slip or 
 >ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
 >with what all these people say, since With all the comments received I 
 >would look very foolish.  SOOOOOOO, someone please tell me how I can use 
 >mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
 >account!!!

If you have a normal shell account on a UNIX host that is connected to the
Internet, even behind a firewall, you can run Mosaic and other X clients on
the UNIX host and display them to your async connected UNIX box running
XFree using the term socket programs.  You can also use term to redirect
socket requests on your local machine to a proxy server on the internet.  Or
you can run special term versions of mosaic and lynx.  None of these
requires slip or ppp.


-- 
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765   ___________________
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.    /   _____  ______ 
  Flint, MI 48504      ellis@nova.gmi.edu               /        / /  /  / /
  Gopher,chimera,nn,tin,jove,modems, free code is best!/________/ /  /  / /

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 94 17:48:30 GMT
From:      ellis@nova.gmi.edu (R. Stewart Ellis)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

root@dolphin.csudh.edu (Jon Stevens) writes:

 >Name withheld upon request (usully@mcl.ucsb.edu) wrote:
 
 >: Several people have responded to say that mosaic can in fact be run 
 >: unix.  The fact still remains that I have yet to see mosaic run on unix, 
 >: and everyone has told me so far that to run mosaic you need a slip or 
 >: ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
 >: with what all these people say, since With all the comments received I 
 >: would look very foolish.  SOOOOOOO, someone please tell me how I can use 
 >: mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
 >: account!!!
 
 >In your original message you wrote:
 >While I am not a expert on this, I am preety sure even if their was a
 >firewall and you did have chmod access, you still would not be able to
 >use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not
 >made for unix, only as a pc or mac app that will only run with a direct
 >connection, i.e if you have slip or ethernet
 >-------------
 
 >You are NOW adding that you would like to do it without slip or ppp...you 
 >did not say that before...without slip or ppp or "direct ethernet" you 
 >can't run any form of Mosaic (Mac,PC,X)...but you can easily run lynx on 
Ddddiiinnngggg!!! wrong answer.  I run Mosaic all the time without any of
the above using a term socket connection between a Sun at home and one at
work.  PC's can run X at home under DOS or windoze and connect with several
products of the ilk of Xremote.

 >a unix host. Yes, you DID look foolish. Also, JUST because you have not 
 >SEEN it run on Unix does not mean that it exists. In fact....I would say 
 >that XMosaic is the application that the people at NCSA update first.

Now who looks foolish!

 >-Jon Stevens
 >root@dolphin.csudh.edu
 >http://dolphin.csudh.edu/


-- 
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765   ___________________
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.    /   _____  ______ 
  Flint, MI 48504      ellis@nova.gmi.edu               /        / /  /  / /
  Gopher,chimera,nn,tin,jove,modems, free code is best!/________/ /  /  / /

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 18:42:39 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP vs. BOOTP

In article <32ssenINN6ou@galaxy.uci.agh.edu.pl> szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:
>Doug Hughes (doug@eng.auburn.edu) wrote:
>
>: RARP = I broadcast ethernet MAC address, you give me IP address. end of
>:        conversation.
 
>: BOOTP = I broadcast ethernet MAC address, you give me IP address, default
>: gateway, nameserver, subnet mask, possibly microcode, maybe a cookie,
>: and other options. IP address is fixed in a table.
>
>This misses one IMHO important point:
>RARP request is an Ethernet broadcast. It is not an IP packet - well, it
>is RARP packet :-) Thus it cannot be routed.
>BOOTP request is an UDP packet - ie. it is IP packet and thus can be forwarded
>if your router has an option of passing UDP broadcasts (CISCO has, for 
>example). For this reason, RARP is suitable for simple LANs, but if you have
>a more complex topology, BOOTP is better.
>There is nothing to stop you from writing a daemon that will assign addresses
>dynamically to RARP requests. Modyfing a standard rarpd to do so should be
>a matter of 2-3 hours.
> ...

That is partly wrong.  Because BOOTP requests are broadcasts, they cannot
be and are not IP-forwarded by any worthwhile router, including Cisco's
or any UNIX workstation running code derived from the Stanford BOOTP
code.  Broadcast IP packets are simply not and must not be forwarded.
Instead, Cisco and workstations act as BOOTP proxies, passing on the
requests.  This sounds like some kind forwarding, and at a sufficient
distance it is like IP forwarding.  However, it is not IP forwarding.

If the religious proscriptions on forwarding broadcast IP packets are
not compelling, remember that the purpose of the game is to get an IP
address.  The requester cannot have a good IP address to use as the
source address in its request, and so according to section 3 in RFC-951,
uses 0.  If the router simply forwarded the request, there would be no
good source IP address and answers could not get back to the requester.

In principle, you could build a RARP proxy similar to a BOOTP proxy
(or "helper" as Cisco calls it).  There is no reason to.

As Szymon Sokol writes, both protocols have nothing to say on whether
the addresses they deliver are dynamically assigned or come from a static
table.  That is mostly an implementation issue entirely independent of
the protocols.  It is not completely an implementation issue, because
if you have ever tried to design real life, professional grade dynamic
IP address assignment mechanisms, you immediately encounter questions
like "how do you know when an IP address is no longer used by a box"
and "how do you accomodate semi-dynamic hostname assignment allowing
the user some choice in hostname?".  Those questions need help from the
protocol that simple RARP and BOOTP do not provide.


Vernon Schryver    vjs@rhyolite.com

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 94 20:43:19 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: Andrew File System

In article <CunDCI.Fw2@da_vinci.ecte.uswc.uswest.com> steveTow@rainbow.ecte.uswc.uswest.com writes:
>
>I am looking for information on the Andrew File System...RFC's, specifications, 
>vendors, etc.  Any pointers to electronic sources?  Any pointers to written 
>experiences with AFS?
>
>Thank you...
>
>steveTow

How about some personal experience with it?

It is slow, unreliable, servers need to be restarted every week (!), 
incompatible, proprietary, not available for many OS's (e.g. Linux), 
un UN*X like (chmod doesn't work totally right!), no support for anything 
except files, directories, and symlinks (_NO_ devices, sockets, fifos), 
hardlinks can not be made from a file in one directory to anywhere outside 
_that directory_, hard to administer, buggy (race conditions in servers 
causing crashes and corruption, clients have been know to eat the AFS 
initialization files on the workstation, AFS cache corruption causing 
programs to stop working on a machine until root clears the cache [after 
downing the machine of course], also _ONE_ bad packet once crashed a whole 
university's AFS system, all clients paniced and rebooted.), no 
source unless you really pay, non-redistributable, ugly, few people 
know how to administer (unlike NFS!), etc

AFS, just say NO!

Kerberized NFS is much better (we run that here). I'd sell my soul to get 
KNFS if I was still stuck with AFS.

If you insist on AFS, Transarc (transarc.com) is the source.

They are in Pittsburgh, PA.

But even they are dumping AFS for DFS (which hopefully will be better, 
can't be much worse)

As for RFCs, etc, its not like NFS, you can't get docs on much of it 
(proprietary), you can get some old stuff for some parts of it (like the 
non-standard RPC they use) but its hard to find.


-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 21:08:17 GMT
From:      bhaskar@brtph181.bnr.ca (Shaji Bhaskar)
To:        comp.protocols.tcp-ip
Subject:   Re: Any vendors of TCP (without IP)?

In article <32tkah$o7n@aisun.aiinet.com> tom@aisun.aiinet.com (Tom Herbert) writes:

>I see some problems in trying to do TCP without IP encapsulation in that
>TCP connections and the protocol itself are linked to the IP addresses
>of the communicating hosts.

I believe you are incorrect.  Reasons are given below.

>RFC 793 says that the IP source and destination addresses are used
>in the calculation of the TCP checksum.  So unless you're going depart
>from the TCP spec, you'll need to provide some kind of addresses (possibly
>bogus) to do this calculation.

You are looking at that part of the spec in isolation.  Look at
Section 1.4 that says:

  The interface between TCP and lower level protocol is essentially
  unspecified except that it is assumed there is a mechanism whereby the
  two levels can asynchronously pass information to each other.
  Typically, one expects the lower level protocol to specify this
  interface.  TCP is designed to work in a very general environment of
  interconnected networks.  THE LOWER LEVEL PROTOCOL WHICH IS ASSUMED
  THROUGHOUT THIS DOCUMENT IS THE INTERNET PROTOCOL [2]. (caps mine).

It is this assumption that leads to places in the text of RFC793, such
as the one you mention, where IP apparently tied to TCP.

Also, look at Section 3.8, under "TCP/Lower-Level Interface":

    The TCP calls on a lower level protocol module to actually send and
    receive information over a network.  One case is that of the ARPA
    internetwork system where the lower level module is the Internet
    Protocol (IP) [2].

This pretty much spells it out.  There are other places in RFC793 that
say things that begin with "If the underlying protocol is IP" or words
to that effect.

Shaji Bhaskar
BNR, NC 27713
-- 
----------------------------------------------------------------------------
Shaji Bhaskar                                             bhaskar@bnr.ca
BNR, Research Triangle Park, NC 27709, USA                (919) 991 7125

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 08:59:10 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32u7o4$5bv@netaxs.com> soneill@unix2.netaxs.com (Steve O'Neill) writes:
>
>What PPP and SLIP have to do with it is simply a matter of 8-bit
>communication with a UNIX system. If you have a remote(modem) connection to
>a system by means of an operating system shell, then you will only get 7-bit
>ASCII characters sent to you by the system. 

   More misinformation.  

   A simple stty -a or stty -everything on an 8-bit connection or even
   an 8-bit telnet connection would quickly prove that many unixes
   allow or even default to CS8 mode.  

   This has absolutely NOTHING to do with whether or not you can run
   Mosaic.  You need a GUI capable connection to run Mosaic.  

>This text-only communication is
>standard on most systems that have shell accounts. 
  
   Within fairly narrow limits, close enough to true.  More formally
   there is a major difference between a 'tty' style connection
   to unix and a tcp/ip type connection which is what SLIP and PPP
   offer.  It is kinda difficult to send X11 data and commands thru
   an ordinary tty type connection....since it lacks the underlying
   protocol stack of tcp/ip. 

   All of the Mosaic implementations I've seen use one of the X11
   variants to pass the graphics.  This is strictly a matter of
   implementation.  If you have X11, you need another protocol stack
   under it to run the X on.  This is why you need PPP or SLIP
   connections. 

   On the other hand, there is nothing at all technically impossible
   that would prevent running full graphics over an ordinary tty link
   using CS8 mode to a PC or terminal that has the extended graphic
   ASCII characters.  It would be a bit ugly, but not at all
   impossible--its just that the hard part is finding code that does
   this.  

   As far as the rest of the misinformation, you can run shell's over
   X type connections in text mode, either CS7 or CS8, as the window
   I'm typing this on is pretty decent evidence of. 



   

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Aug 1994 21:37:17 GMT
From:      srtow@future.mnet.uswest.com
To:        comp.protocols.tcp-ip
Subject:   Andrew File System (AFS)


I am doing some research into the pros and cons of converting from NFS to AFS 
and would like to locate as much information on AFS as I can. Does there exist 
an RFC (one or more) which specifies the AFS? Any pointers to documented 
experiences with conversion? Is this the right group for this?

Thanks in advance...

steveTow

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 11:23:16 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: TCP/IP Host Naming Conventions?

>In article <32vnhj$v99@blue.weeg.uiowa.edu> pkoch@blue.weeg.uiowa.edu
>(Peter F Koch) writes:
>
>:We would like any comments or suggestions on naming conventions 
>:for tcp-ip hosts that people use? For instance, do you name 
>:machines based on a certain theme or do you name hosts based on 
>:a specific function, etc.  What are the benefits of the naming
>:convention?  Our laboratory is thinking of naming PC hosts based
>:on it's function (i.e. balance, instrument1).  The problem is, 
>:the PC can be moved to another
>:location in the lab and perform a totally different function, 
>:therefore requiring a name change.  Wouldn't it be easier maintenance 
>:wise to just give the host a name (like a person) instead of changing
>:the name of it's function and changing the host files.  We are new to 
>:tcp-ip, so please forgive our ignorance.

  There is no real requirement whatsoever on naming hosts.  If yours
  are susceptible to being moved to another "function", it would seem
  best to avoid using the function name as the hostname.

  You have no idea just how much of a pain and task it is to EVER rename
  a host.  So many things just don't work any more until you dig out
  each and every procedure, shell script, private config file, etc.
  etc. where the host name is of significance. 

  Maybe you could assign thematic workgroup names to the
  hosts...possibly based on budget considerations such that although
  a given PC might be moved to another function and/or location, it
  would never leave the department etc.   

  Many hostnames are humorous insider-jokes related to their function
  or the functions, hobbies, etc. of the users.  This trend seems to
  be diminishing, sadly. 



-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 23:50:28 GMT
From:      soneill@unix2.netaxs.com (Steve O'Neill)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32tai9$clk@news.panix.com> berke@panix.com (Wayne Berke) writes:
>
>	...(stuff deleted)
>
>Am I missing something?  What does the PPP or SLIP have to do with anything?
>Won't any form of Internet connection do?  Granted without an Internet
>connection you wouldn't be able to run Mosaic, but isn't that true for
>lynx also?
>
>	...(other stuff deleted)>
>--
>Wayne Berke
>berke@panix.com

What PPP and SLIP have to do with it is simply a matter of 8-bit
communication with a UNIX system. If you have a remote(modem) connection to
a system by means of an operating system shell, then you will only get 7-bit
ASCII characters sent to you by the system. This text-only communication is
standard on most systems that have shell accounts. On the other hand, when
you have a PPP or SLIP connection, you "look" to the UNIX system like just
another station on its local network, and, therefore, can be sent full 8-bit
bytes. This means that any image data that is coming to you can be received
and stored AS image data. It is true that without a SLIP or PPP connection
you can't run Mosaic, since it is designed to "talk" directly to a network.
However, if you have shell account, you can run lynx on your provider's
system to get textual output only to your system. In other words, you run
Mosaic on YOUR machine through a PPP or SLIP connection to make your machine
an extension of your provider's network, and you run lynx on your provider's
machine to get textual output from him.

Steve O'Neill


-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 08:26:11 -0500
From:      pkoch@blue.weeg.uiowa.edu (Peter F Koch)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip
Subject:   TCP/IP Host Naming Conventions?

We would like any comments or suggestions on naming conventions 
for tcp-ip hosts that people use? For instance, do you name 
machines based on a certain theme or do you name hosts based on 
a specific function, etc.  What are the benefits of the naming
convention?  Our laboratory is thinking of naming PC hosts based
on it's function (i.e. balance, instrument1).  The problem is, 
the PC can be moved to another
location in the lab and perform a totally different function, 
therefore requiring a name change.  Wouldn't it be easier maintenance 
wise to just give the host a name (like a person) instead of changing
the name of it's function and changing the host files.  We are new to 
tcp-ip, so please forgive our ignorance.

    //    //  ////// //////  ////////  //////  ///   // Pete Koch
   //    //  //     //         //     //  //  ////  // Weston Gulf Coast Labs
  // // //  ////     //       //     //  //  // // // 2417 Bond St.
 // // //  //          //    //     //  //  //  //// University Park, IL 60466
////////  //////  //////    //     //////  //   /// pkoch@umaxc.weeg.uiowa.edu
================================================== 708-534-5200


-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 07:12:28 -0400
From:      sorcerer@strauss.udel.edu (Xuewu Zhu)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall


The company I work for runs firewall.  There are at least two ways that
you can run Mosaic through firewall.  One is to compile Mosaic with
-DSOCKS option if you are running socks protocol; the other is to set
up CERN Mosaic as a proxy on your firewall/gateway machine.  Both are
being used without any problems at my place.

My machine is a Sun Sparc IPC running SunOS 4.1.3_U1 and X11R5.  I 
understand that X11R4 will work just as well.



-- 
| E-mail:  sorcerer@brahms.udel.edu  |  				!
|	   sorcerer@freezer.udel.edu |  I will just leave it "blank" 	|
| Computer & Information Sciences    |  here since that is often the 	|
| University of Delaware 	     |  state of my mind.		|

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 1994 01:15:50 GMT
From:      al395@FreeNet.Carleton.CA (Lance Lu)
To:        comp.protocols.tcp-ip
Subject:   How to pass argument  to func_handle in signal function call??


How to pass arguments to func_handle in signal( SIGTERM, func )?

Thank you in advance.

Lance
--
*******************************************
al395@freenet.carleton.ca

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 01:58:53 GMT
From:      awsmith@news.neosoft.com (Andrew Smith)
To:        comp.security.unix,comp.protocols.tcp-ip,comp.infosystems.www,alt.internet.services
Subject:   Re: Bypassing internet firewall

[ bickering, etc deleted ]

Methinks that this person who is asking this question has a unix shell
account with an internet provider and wrongly assumed that Mosaic was
available for Macintosh and Windows based PC's because from this person's
end, the only place they had experienced it from was seeing other people's
SLIP or PPP accounts. To put it in a nutshell, to run Mosaic on a unix
machine, you must have an ip address for the machine that you will be
viewing it from (the DISPLAY variable). This is impossible over a dialup
non-SLIP/PPP connection because you are _accessing_ the unix machine...
not _connected_ to it. I assume that either this person's provider doesn't
offer SLIP/PPP or this person either can't afford, or doesn't want to pay
extra, for the SLIP/PPP account. If this person is running unix on their
personal PC, they still need a SLIP/PPP connection. (oh...and just in case
it hasn't been mentioned...you can get Xmosaic for Xwindows running on...
*drumroll please* UNIX)

--
Andrew Smith        ** 1-800-GET-NEOSoft ** email info@neosoft.com for info
awsmith@neosoft.com ** (713) 684-5969    ** sysop@neosoft.com for support

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 94 02:15:17 GMT
From:      brian@ilinx.com (Brian J. Murrell)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP vs. BOOTP

doug@eng.auburn.edu (Doug Hughes) writes:

>BOOTP = I broadcast ethernet MAC address, you give me IP address, default
>gateway, nameserver, subnet mask, possibly microcode, maybe a cookie,
good for when you get those mid day growlies!!---------^^^^^^^^^^^^^^
BTW: is there a selection or only chocolate chip?? :-)

>and other options. IP address is fixed in a table.
 
>DHCP = like BOOTP - but IP address is dynamic. (in a nutshell)
My question is with a net full of PC's I like to be able to do a
"ping peter_pc" and find out if Peter's PC is alive.  How will one
do that if the IP address changes every time they boot??  Will the
hostname<->IP addressing be dynamic as well??

b.

-- 
Brian J. Murrell                                               brian@ilinx.com
InterLinx Support Services, Inc.                              brian@wimsey.com
North Vancouver, B.C.                                             604 983 UNIX
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 1994 20:2:37 GMT
From:      aflydal@inet.uni-c.dk (Arno Flydal)
To:        comp.protocols.tcp-ip
Subject:   IP-Address

How do you get the IP-address from SCO-Unix for a paricular workstation
connected to the network. NOT the IP-address for the server, but the
workstation.

If you know a way to get the IP-address, please email me. Thank you.

Arno Flydal
(aflydal@inet.uni-c.dk)


-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 10:06:22 -0400
From:      tom@aisun.aiinet.com (Tom Herbert)
To:        comp.protocols.tcp-ip
Subject:   Re: Any vendors of TCP (without IP)?

In article <1994Aug17.210817.4766@brtph560.bnr.ca> bhaskar@brtph181.bnr.ca (Shaji Bhaskar) writes:
>In article <32tkah$o7n@aisun.aiinet.com> tom@aisun.aiinet.com (Tom Herbert) writes:
>
>  The interface between TCP and lower level protocol is essentially
>  unspecified except that it is assumed there is a mechanism whereby the
>  two levels can asynchronously pass information to each other.
>  Typically, one expects the lower level protocol to specify this
>  interface.  TCP is designed to work in a very general environment of
>  interconnected networks.  THE LOWER LEVEL PROTOCOL WHICH IS ASSUMED
>  THROUGHOUT THIS DOCUMENT IS THE INTERNET PROTOCOL [2]. (caps mine).
>
>It is this assumption that leads to places in the text of RFC793, such
>as the one you mention, where IP apparently tied to TCP.
>

This is all true, with the right hacks I'm you could stuff TCP packets
directly into ethernet frames if you wanted.

My point is that once you take away the IP encapsulation from TCP, odds are
you are immediately making yourself inoperable with most vendors who have
implemented 793 (with IP in mind).  If you'll NEVER have to communicate with
another vendor, or you'll NEVER need to route across IP networks, then I
say go for it.


Tom Herbert
Applied Innovation Inc.
Dublin, OH

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 94 09:04:46 CDT
From:      berkley@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip
Subject:   TCP/IP print sharing???

Okay, here's a shot in the dark. . . .

Does ANYONE know of some software (share/free/commercial, no matter) that 
will allow you to have two PCs share a printer?  (Obviously, neither of them
are running UNIX, but DOS.)  The program must not completely tie up either
machine.  Also, what TCP/IP stack does it run with.  (I'd prefer LAN WorkPlace
for DOS, but I'm slightly flexible.)

Please E-mail directly.  If I find a good result, I'll post.  Thanks!

                                -- Travis

BERKLEY@CCSTAFF.WPO.UKANS.EDU
BERKLEY@KUHUB.CC.UKANS.EDU
Travis J. Berkley, Information Technology Analyst
University of Kansas, LAN Support Services

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 94 04:27:51 GMT
From:      ccbsc@marlin.jcu.edu.au (Brad Cooper)
To:        comp.protocols.tcp-ip,comp.unix.osf.misc,comp.unix.osf.osf1
Subject:   DHCP server daemons.

I am trying to standardise at this university on DHCP and notice now that
quite a few clients are available. Unfortunately I haven't managed to
find any server daemons.

We are running the latest versions of Ultrix and OSF/1 (basically DEC's
BSD Unix operating systems). I have scoured the Internet looking for
DHCP server daemons and BOOTP daemons with DHCP support and cannot come
up with anything - for any operating system. Could you please let me
know if any server daemons exist yet and where I may find them? Any help
will be greatly appreciated.

-- 
Regards, Brad Cooper		Internet:Brad.Cooper@jcu.edu.au
Manager, Networking & Comms	Phone:+61 77 814245
Computer Centre			  Fax:+61 77 815230
James Cook University

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 1994 12:31:29 +1000
From:      dave@eram.esi.com.au (Dave Horsfall)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

In article <1994Aug15.122022.21200@pcthree.com>,
    scum@pcthree.com (Steve Monroe) writes:

| That's if you can find it to run on your Dell 2.2.  PPP on PC/Unix
| seems to be largely ignored by commercial and free markets.

Unless I've misinterpreted your remark, that's news to me.  PPP is
available for commercial BSD/386 and free Linux.  So is SLIP, but I
don't use it.  There is also a free version that runs on Ultrix, Net/BSD,
SunOS, etc etc.

-- 
Dave Horsfall (VK2KFU) | dave@esi.com.au | VK2KFU @ VK2AAB.NSW.AUS.OC | PGP 2.6
Opinions expressed are mine. | E7 FE 97 88 E5 02 3C AE  9C 8C 54 5B 9A D4 A0 CD

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 17:36:06 -0700
From:      eddy@girtab.usc.edu (George Edmond Eddy)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP "destination unreachable" error question

kstailey@leidecker.std.com (Kenneth Stailey) writes:

>I know that ICMP "destination unreachable" (specifically port
>unreachable) errors are generated in response to receiving UDP packets
>(other than broadcast packets) addressed to ports that have no listens
>posted.
 
>My question is on UN*X systems (esp. HP-UX) does anything else cause
>an ICMP destination unreachable error?
 
>Searching through 4.3BSD sources, I only found calls to icmp_error()
>in udp_usrreq().
 
>Thanks,
>Ken

destination unreachable should be generated from the first router 
that recieves a packet yet has no specific route to the host or a default route.  this is 
completely different than "port unreachable".

--

- rusty

eddy@usc.edu
-- 

- rusty

eddy@usc.edu

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 17:48:28 -0700
From:      eddy@aludra.usc.edu (George Edmond Eddy)
To:        comp.protocols.tcp-ip
Subject:   Re: traffic generator

grandjen@georges.montefiore.ulg.ac.be (Grandjean Vincent) writes:

>Hello,
 
>I'm looking for articles or other information on traffic simulation (model).
>I'm looking for examples of :
>	- times between UDP datagrams,
>	- times between TCP segments,
>	- size of TCP windows,
>	- size of UDP datagrams,
>	- size of TCP segment,
>	- ...
>in FTP, RLOGIN, TELNEL applications
 
>Thank you for any help,
 
>-Grandjean Vincent, e-mail grandjen@montefiore.ulg.ac.be

check out anonymous ftp: catarina.usc.edu:/pub/jamin you will find
three directories: traffic, tcplib and collect.  traffic contains
a published journal article on various types of IP traffic, ftp, 
telnet, smtp, nntp, nv and vat.  collect on the method of collection
and tcplib which is a library that can be used to emulate the 
random distribution of packet size, session length and interpacket gaps...

i am writing a traffic generator using the above to create realistic
traffic of the various types.

hope this helps...

--

- rusty

eddy@usc.edu

-- 

- rusty

eddy@usc.edu

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 13:55:48 -0400
From:      jwmanly@unix.amherst.edu (John W. Manly)
To:        comp.protocols.tcp-ip
Subject:   Ethernet numbers

Hi there.  I was hoping someone could point me in the right direction
(document, RFC, whatever) that could tell me

1) All the currently defined ethernet protocols and their associated
numbers, such as IP, DECNET, LAT, IPX.

2) All the assigned ethernet hardware address fields.  (DEC, for example
has 08-00 and AA-00 as the first two bytes of all ethernet address of
all equipment that they manufacture.)

Thanks!  (Please respond via E-mail if it isn't too inconvenient.)

-- John W. Manly  <JWMANLY@AMHERST.EDU> (System Manager -- Amherst College)

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 1994 15:36:20
From:      tnemeth@immuno.imvs.sa.gov.au (Tom Nemeth)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet

In article <1994Aug16.191822.25246@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
>From: jrd@cc.usu.edu (Joe Doupnik)
>Subject: Re: scripted telnet
>Date: 16 Aug 94 19:18:21 MDT
 
>In article <CuMu0o.Dxz@ncifcrf.gov>, brownje@ncifcrf.gov (Janet E. Brown) writes:
 
>>>>Can anyone point me to a version of telnet (source if poss) which 
>>>>supports scripting, a bit like comms programs for PCs do?
>> 
>> [Response concerning Kermit and Expect]
>> 
 
>-----------
>        Maybe I'm giving away secrets here, Microsoft's secrets fortunately.
>Take the case of MS-DOS Kermit running in Windows. 

We do exactly that, but I really would like Kermit to be able to interface to 
the new MS TCP/IP stack.  I guess it would have to use the Winsock API 
interface from DOS.

>        Kermit can run on the top of FTP Inc's TNGLASS Int 14h interface,
>but specifying a particular host needs to be expressed on the TNGLASS
>command line.

But I don't want to do that!  I already have MS TCP/IP Winsock, why can't 
Kermit just use that?  MS provides (DOS versions of) ping, traceroute, 
ipconfig, etc. etc. which does exactly that; why can't Kermit?

Tom  Nemeth

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 10:42:53 GMT
From:      markolf@lfbs.rwth-aachen.de (Markolf Gudjons)
To:        comp.infosystems.www,comp.protocols.tcp-ip,alt.internet.services
Subject:   Re: Bypassing internet firewall

Chris Anderson (caa@unify.com) wrote:
> As far as running Xmosaic, if you have X windows and the motif libraries, 
> then you can run Xmosaic.
And you don't even need the Motif libs if you're getting the binary
version. It's statically linked.

--
|  _      :  Markolf Gudjons, Lehrstuhl fuer Betriebssysteme         DoD  #784
|_|_`__   :  RWTH Aachen, Kopernikusstr. 16, D-52056 Aachen	     __=o&o>__
  | |__)  :  Tel.   :  +49-(241) 80-6344  |  Fax : +49-(241) 8888-339
    |__)  :  e-Mail :  markolf@lfbs.rwth-aachen.de             GS 500 E - Suzi
             WWW    :  http://www.lfbs.rwth-aachen.de         GPX 600 R - Kwak

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 16:14:52 -0300
From:      bmcmulli@fox.nstn.ns.ca (Bill McMullin)
To:        comp.protocols.tcp-ip
Subject:   Mac using Ethernet & SLIP

I have an Ethernet card in my Mac I use to telnet
to our Unix box and I also have MacSLIP which I use
to dial-up to my local Internet provider.

Problem:  I have to reconfigure MacTCP and reboot
each time I want to connect to the other.

Any help appreciated.

-- 
Bill McMullin                        E-mail: bmcmulli@fox.nstn.ns.ca
InterActive Telecom                      ph: 902-832-1014
1550 Bedford Hwy Sun Tower #304          fx: 902-832-1015
Bedford, Nova Scotia,           
Canada B4A 1E6                  

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 12:36:46 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Andrew File System (AFS)

In article <Cup84B.Fn6@da_vinci.ecte.uswc.uswest.com>, srtow@future.mnet.uswest.com writes:
|> 
|> I am doing some research into the pros and cons of converting from NFS to AFS 
|> and would like to locate as much information on AFS as I can. Does there exist 
|> an RFC (one or more) which specifies the AFS? Any pointers to documented 
|> experiences with conversion? Is this the right group for this?

No, there's no RFC for it; it's a proprietary commercial product made
by Transarc, a spin-off from Carnegie-Mellon University in Pittsburgh
(thus the name "Andrew").  They're on the net as transarc.com, whois
gives an address of:

Transarc Corporation (TRANSARC-DOM)
   The Gulf Tower
   707 Grant Street
   Pittsburgh, PA 15219

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 2618

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 94 00:22:22 -0700
From:      tcray@dtr.stat.com (Teri Ray)
To:        comp.protocols.tcp-ip
Subject:   Re: FREE TCP/IP

>In article <CuIFro.Dtr@adl33cc.adelphi.edu> fischman@auvax1.adelphi.edu writes:
 
>	   Could someone please tell me if there is any sort of 
>   "public domain" TCP/IP software that I can use to communicate
>   with my NetWare v3.11 server, and where I can get it?
 
>Sure.  Get the Crynwr packet driver collection.  In it you'll find a
>bunch of Ethernet drivers.  You'll also find an IPX (in PDIPX103.ZIP)
>that runs over those drivers (it expects to use IEEE_802.3 binding).
>You'll also find SOFTWARE.DOC, which lists free software that runs
>over packet drivers.
 
>And once you outgrow the free stuff, there are a number of commercial
>TCP/IP packages that run over packet drivers.

Could someone please tell ME if there is any sort of freeware TCP/IP 
software that I can use to communicate with my peer-to-peer DOS LAN 
(which uses NETBios) ?  I have a packet driver for my Invisible LAN
software already.  Also could I get a pointer to whatever FAQs 
are available for extreme newbies regarding TCP/IP, packet drivers,
and general communications between DOS & Unix machines?  I'd appreciate
your help.

-- 
Teri Ray     * RIME: 1532 or DATATERM    * Internet: tcray@dtr.stat.com
DTR BBS      * CIS: 71331,2467           * BBS: 1 602 993 4753/8N1/v.32

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 19:51:23 -0400
From:      kevin@cfc.com (Kevin Darcy)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip
Subject:   Re: TCP/IP Host Naming Conventions?

In article <32vnhj$v99@blue.weeg.uiowa.edu>,
Peter F Koch <pkoch@blue.weeg.uiowa.edu> wrote:
>We would like any comments or suggestions on naming conventions 
>for tcp-ip hosts that people use? For instance, do you name 
>machines based on a certain theme or do you name hosts based on 
>a specific function, etc.  What are the benefits of the naming
>convention?  Our laboratory is thinking of naming PC hosts based
>on it's function (i.e. balance, instrument1).  The problem is, 
>the PC can be moved to another
>location in the lab and perform a totally different function, 
>therefore requiring a name change.  Wouldn't it be easier maintenance 
>wise to just give the host a name (like a person) instead of changing
>the name of it's function and changing the host files.  We are new to 
>tcp-ip, so please forgive our ignorance.

Check out RFC 1178 at an RFC repository near you...

--------------------------------------------------------------------------------
kevin@cfc.com <-- (ASCII only please)  | Kevin Darcy, UNIX Systems Admin (CFC)
kevin@tech.mis.cfc.com <-- (mute       | Technical Services
Voice: (810) 759-7140 	    NeXTmail   | Chrysler Corporation
Fax:   (810) 758-8173       welcome)   | Center Line, Michigan, MIS Complex
--------------------------------------------------------------------------------

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 14:27:20 GMT
From:      pluvius@dragon.achilles.net (pluvius)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

: SOOOOOOO, someone please tell me how I can use 
: mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
: account!!!

You need to be running X on your local display. A term program will not do
it. If you have a unix account but do not have SLIP or PPP then you are SOL.
However, i think that there is a version of mosiac out there that will work
over TERM connections, so what you could do is install TERM on your unix
account, fire up TERM on your linux box, and snag a copy of Mosiac for 
TERM connections.

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 14:54:53 GMT
From:      mjo@iao.ford.com (Mike O'Connor)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip
Subject:   Re: TCP/IP Host Naming Conventions?

In article <32vnhj$v99@blue.weeg.uiowa.edu> pkoch@blue.weeg.uiowa.edu
(Peter F Koch) writes:

:We would like any comments or suggestions on naming conventions 
:for tcp-ip hosts that people use? For instance, do you name 
:machines based on a certain theme or do you name hosts based on 
:a specific function, etc.  What are the benefits of the naming
:convention?  Our laboratory is thinking of naming PC hosts based
:on it's function (i.e. balance, instrument1).  The problem is, 
:the PC can be moved to another
:location in the lab and perform a totally different function, 
:therefore requiring a name change.  Wouldn't it be easier maintenance 
:wise to just give the host a name (like a person) instead of changing
:the name of it's function and changing the host files.  We are new to 
:tcp-ip, so please forgive our ignorance.

One resource is RFC 1178, "Choosing a Name for Your Computer", which
is available via anonymous FTP from ftp.internic.net:/rfc/rfc1178.txt.

RFCs (Request For Comments) are specifications and guidelines for how
many aspects of TCP/IP and the Internet (should) work.  Most RFCs are
fairly technical documents, and some have semantics that are hotly
contested in the newsgroups.  But a few, like RFC 1178, are actually
good to read for someone who's just starting along a TCP/IP path.

						...Mike
-- 
 Michael J. O'Connor           |  Internet:  mjo@jobone.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!fmsrl7!opeo!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 15:43:03 GMT
From:      wardc@europa.eng.gtefsd.com (Cliff Ward)
To:        comp.protocols.tcp-ip
Subject:   GOSIP-2 Protocol for PC?

 Are there any companies that have a GOSIP-2 compliant network protocol 
for PCs?  I see mention of GOSIP-2 on servers such as Sun, but what I am 
wondering is how an end user from a PC would gain access to that protocol.

Thanks,

Cliff Ward



-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 94 21:51:49 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.unix.admin
Subject:   Re: scripted telnet

In article <tnemeth.73.000F9B85@immuno.imvs.sa.gov.au>, tnemeth@immuno.imvs.sa.gov.au (Tom Nemeth) writes:
> In article <1994Aug16.191822.25246@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
>>From: jrd@cc.usu.edu (Joe Doupnik)
>>Subject: Re: scripted telnet
>>Date: 16 Aug 94 19:18:21 MDT
 
>>In article <CuMu0o.Dxz@ncifcrf.gov>, brownje@ncifcrf.gov (Janet E. Brown) writes:
 
>>>>>Can anyone point me to a version of telnet (source if poss) which 
>>>>>supports scripting, a bit like comms programs for PCs do?
>>> 
>>> [Response concerning Kermit and Expect]
>>> 
 
>>-----------
>>        Maybe I'm giving away secrets here, Microsoft's secrets fortunately.
>>Take the case of MS-DOS Kermit running in Windows. 
> 
> We do exactly that, but I really would like Kermit to be able to interface to 
> the new MS TCP/IP stack.  I guess it would have to use the Winsock API 
> interface from DOS.
> 
>>        Kermit can run on the top of FTP Inc's TNGLASS Int 14h interface,
>>but specifying a particular host needs to be expressed on the TNGLASS
>>command line.
> 
> But I don't want to do that!  I already have MS TCP/IP Winsock, why can't 
> Kermit just use that?  MS provides (DOS versions of) ping, traceroute, 
> ipconfig, etc. etc. which does exactly that; why can't Kermit?
> 
> Tom  Nemeth
----------------
	Well, Tom, the reason is very simple: the MS TCP/IP stack is a
full Windows program and totally tied to support from/by Windows. It
can't run as a DOS program. DOS programs are not tied to Windows at all.
There is a vast difference between these two kinds, and technically they
just don't mix or integrate. We would very much like to write a pure
Windows version of Kermit, but that takes people time and money of which 
we have none available presently. Ask the other comms program vendors
how many person-years they invested to create Windows versions.
	Joe D.

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 16:13:48 GMT
From:      smckinty@sunicnc.France.Sun.COM (Steve McKinty - SunSoft ICNC Grenoble)
To:        comp.protocols.tcp-ip
Subject:   Multiple IP networks on a single (bridge-linked) ethernet



Just before I put my foot too deeply in it, can someone confirm something
for me please:

Assuming that I currently have two twisted-pair ethernet networks,
each on separate hubs, and each connecting to an interface on a host
computer, with other systems hung of the Hubs.

Hub---Hub---Hub--->HOST<---Hub---Hub---Hub

Each network is assigned an IP address, and the HOST is set to route
IP packets between the networks.

I want to change this to:

Hub---Hub---Hub--->BRIDGE<---Hub---Hub---Hub
	     |
	   HOST

So that I can get non-IP (e.g. IPX/SPX, X.25 etc) packets between the
networks. Assume that all the systems connected to the hubs retain
their original IP addresses.

Is there any problem with this scenario, insofar as I'll be running
two IP networks on the same ethernet?  Since the host will then only
have one interface, with one IP address, how do systems on the other
network find it?

I'm sure this is elementary, but I'm not an IP expert (if that isn't
already obvious)...

Thanks

Steve


-- 
Steve McKinty
Sun Microsystems ICNC
38240 Meylan, France
email: smckinty@france.sun.com

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 94 16:26:58 GMT
From:      gpaloni@mcs.drexel.edu (Prasad Aloni)
To:        comp.protocols.tcp-ip
Subject:   SNMP Agents For Windows/PCs.

I am looking for  SNMP agent software for PC/Windows environment. Any good
suggestions ? I also understand there are NICs available with SNMP agents right
on them. What type of details do they provide about the machine that they run
on ? All suggestions greatly appreciated.

Prasad Aloni, gpaloni@mcs.drexel.edu.

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 1994 17:45:12 GMT
From:      kshin@eskimo.com (Kevin Shin)
To:        comp.protocols.tcp-ip
Subject:   detecting server status

I am using select() to wait for server to send input
indefinitly.  However I would lie to detect when server 
goes down.  I've tried setsockopt ( SO_KEEPALIVE ) but
it did not work.
How should it be done?

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 17:53:54 GMT
From:      ce726@cleveland.Freenet.Edu (Lance V. Pawlikowski)
To:        comp.protocols.tcp-ip
Subject:   Need help with telnet script


I'm on a SUN workstation and to get statistics from a router on the
network, I do the following:

# telnet router_name
        (then type in the password at the prompt)
router_name> show version   (on the router now and execute show version)
router_name> quit           (exit the router)
#  (now back at the sun)

I need to do the above from a script which gets the router output from
the 
 show version command. I've tried a "here" document using telnet but
that doesn't work. I can connect but cannot get past the password prompt.
Following is the script I tried using a "here" document:

telnet << END
open router_name
password_name
show version
quit
END >> file_on_sun 2>&1

The 
problem is the password_name in the here document is not being accepted by
telnet. I have a feeling that what I am trying to do with 'telnet' isnt'
possible. Any help or other ideas to accomplish this would be appreciated. 
Thank you.

Lance Pawlikowski

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 94 18:27:07 GMT
From:      yzarn@lhdsy1.lahabra.chevron.com (Philip Yzarn de Louraille)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32roqv$kaa@ucsbuxb.ucsb.edu> usully@mcl.ucsb.edu (Name withheld upon request) writes:
>
>Several people have responded to say that mosaic can in fact be run 
>unix.  The fact still remains that I have yet to see mosaic run on unix, 
>and everyone has told me so far that to run mosaic you need a slip or 
>ethernet account.  Otherwise you cannot run mosaic.  I am not disagreeing 
>with what all these people say, since With all the comments received I 
>would look very foolish.  SOOOOOOO, someone please tell me how I can use 
>mosaic on my unix account instead of lynx, even tho I have no slip or ppp 
>account!!!

If you have a UNIX account, then most certainly the machine the UNIX is
on is running TCP/IP.... So why would you need SLIP or PPP, eh?

Beside, you should not try to bypass your firewall. Your security people
will get pretty paranoid if you do, and you certainly do not want to
bypass the security policies enabled on by your management.

You can have web access through your firewall. Talk to your security
people.
-- 
  Philip Yzarn de Louraille                 Internet: yzarn@chevron.com
  UN*X Systems Specialist                   PROFS:    ZARN(SMTP)
  Chevron Information & Technology Co.      Tel: (310) 694-9232
  P.O. Box 446, La Habra, CA 90633          Fax: (310) 694-7709

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 1994 18:29:44 GMT
From:      Tim Nelson <Tim.Nelson@Canada.NCR.COM>
To:        comp.protocols.tcp-ip
Subject:   Re: Microsoft Wolferine

>In article <32gva1$fhv@otis.apana.org.au> J.J. Pantebre writes: 
>>is there any ftp-server to get microsoft wolverine tcp/ip software from?
>>
>
>yes - try ftp.microsoft.com for beta-3 release. works well but I am still 
 looking for
>a slip or ppp driver that works with it's winsock. Please let me know if you 
find one.>

The release 1.0 is available from that system now.  I too am looking for a winsock
ppp.



tim.nelson@canada.ncr.com
at&t gis canada
+1 905-819-4112




-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 18:33:43 GMT
From:      jsb@speedy.inri.com (J. Spencer Brown)
To:        comp.protocols.tcp-ip
Subject:   TCP checksum

Does anyone out there know what algorithm TCP uses to compute its
checksum.  What data does this include?  Any help would be 
appreciated.

Thanks,

Spencer Brown
jsb@inri.com

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 19:33:24 GMT
From:      rbrandt@hac.com (Richard Brandt)
To:        comp.protocols.tcp-ip
Subject:   1 host, 2 cards, same address?

This isn't in the FAQ and although I've seen it addressed here I don't think
I've gotten the answer I need.  For various applications I've run across, for
redundancy or for load sharing, it seems to be a good idea to have a host that
has 2 interfaces onto the same ethernet or FDDI segment.  That would imply
that the network portion of the IP address for both interfaces would be the
same while the host portion could be different.  Now it seems that I've heard
that at least an older version of SunOS wouldn't let you do that.  I've heard
different stories from different persons on whether that is still true for Sun
and all the other vendors (IBM, HP, DEC, SGI).  What I would like is to hear
from the net is if someone has done this and what if any problems they've had.
If it can be done (and it may be an OS by OS case) how is 1 interface chosen
over another?  The source code for IP seems to take the target IP address and
strip the network portion and then do a table match on the interface cards.
That would imply the same interface is chosen first all the time.

The other question, if this can be done, is what happens if you get an IP 
broadcast?  Wouldn't 2 copies of the same packet go up the stack? 

Thanks!

--
Richard L. Brandt
Hughes Aircraft Company
(303) 344-6586
rbrandt@redwood.hac.com

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 1994 19:35:02 GMT
From:      weizhong@buphy.bu.edu (Weizhong Wang)
To:        comp.protocols.tcp-ip
Subject:   Automatically download file on a Mac

I am not sure if this is the right group to post. If it's not, please 
let me know where I can get help.


I have a Mac which has its own IP address, and I need to download some
data every day from an unix machine.  I  know unix script can do this
job automatically.  Can a mac do this automatically (by fetch, telnet,
ftp..)?

Any help is greatly appreciated.

Thanks.



W. Wang

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 1994 20:34:48 GMT
From:      randy@megatek.com (Randy Davis)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

ames/board/44357 <3 comp.infosystems.www:23327 comp.protocols.tcp-ip:22974 comp.security.unix:7639 alt.internet.services:29892

In article <32qicr$83c@bmerha64.bnr.ca>, Eric Hsiao <hsiaoe@bnr.ca> wrote:
|Sorry for the crossposting, but I'm not exactly sure what group this post would
|fit best in.
|
|Anyway, I want to run Mosaic and be able to connect to WWW sites around the
|world, but the problem is, there's this Internet firewall that prevents me
|from doing so. The firewall pretty much prevents me from using any X based
|clients to connect to anything outside of my own domain.

  I would imagine that the firewall prevents just about *any* traffic from
the internal net to go to the outside world, and vice-versa, unless it goes
through a relay program on the firewall.  That is, if the firewall is
configured correctly, it shouldn't allow anything through except that which
has been expressly allowed, usually through some form of proxy (such as SOCKS)
or actual relay program (such as sendmail).

  Mosaic, or at least NCSA Mosaic-2.4 under UNIX, does not use X protocols to
connect outside of your domain.  It uses http requests.  The only X requests
are between the X client and the X server.  Your firewall SHOULD block X
traffic, since X is known to be pretty unsecure.  Your firewall probably
also blocks http requests, but that is something your admin may be willing
to let through.

| Right now, from my
|workstation, I telnet to the gateway/firewall machine. Once on there, I have
|a very limited set of commands, like telnet, ftp, etc. From there, I can
|go out into the "real world". I cannot run any of my own programs on that
|machine as they have not made 'chmod' available to set r-x permissions.
|For example, if I compile 'ncftp' and ftp it onto that machine, I can't change
|the permissions so I can run it on that machine. Anyway, I'm starting to
|digress, so this is my real question:

  I suggest you discuss the matter with your firewall/network administrator,
instead of trying to circumvent the safeguards that are in place for your
network.  He can install SOCKS on the firewall, and the current NCSA version
of Mosaic (2.4) for UNIX has full SOCKS support that are enabled by a
compile-time switch (as long as it has access to the socks library archive
during compilation).   Since a user with unrestricted access to a firewall
can often open up a hole in the firewall that "bad guys" can easily exploit,
the restrictions in place on your actions on a firewall are probably warranted.

|I want to run Mosaic, but as of now, there's no way I can run X-Clients and
|have them connect to the outside world.

  Which is as it should be.

| I was wondering if there's a program
|like TERM where I can run one end on my workstation and the other end on a
|machine that's not in my domain that would let me run X clients. For example,
|I telnet to the gateway, then from there, telnet out to another machine. 
|Basically, I need a program like TERM but instead of serial lines, it's
|tailored for TELNET connections (two telnet connections in my case...
|my WS -> gateway -> outside machine).

  It sounds like it might be simply easier to get your administrator on
your side, instead of going behind his back.

Randy Davis
randy@megatek.com


-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 1994 20:36:57 GMT
From:      randy@megatek.com (Randy Davis)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

ames/board/44357 <3 comp.infosystems.www:23328 comp.protocols.tcp-ip:22975 comp.security.unix:7640 alt.internet.services:29893

In article <32r8jj$flj@ucsbuxb.ucsb.edu>,
Name withheld upon request <usully@mcl.ucsb.edu> wrote:
|In <32qicr$83c@bmerha64.bnr.ca> hsiaoe@bnr.ca (Eric Hsiao) writes:
|>I want to run Mosaic, but as of now, there's no way I can run X-Clients and
|>have them connect to the outside world. 
|
|While I am not a expert on this, I am preety sure even if their was a 
|firewall and you did have chmod access, you still would not be able to 
|use mosaic!!!  I could be mistaken, but I am VERY SURE that mosaic is not 
|made for unix, only as a pc or mac app that will only run with a direct 
|connection, i.e if you have slip or ethernet

  No, "Name withheld upon request", Mosaic *is* "made" for UNIX.

Randy Davis
randy@megatek.com


-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Aug 1994 21:07:16 GMT
From:      mwm@contessa.phone.net (Mike Meyer)
To:        comp.infosystems.www,comp.protocols.tcp-ip,alt.internet.services
Subject:   Re: Bypassing internet firewall

I can't stand it. There's to much confusion. I'm going to post a
long-winded explanation that somebody is going to correct. Maybe it'll
turn into a FAQ of some kind...

In using a WWW browser to examine information from the net, there are
three systems involved. We're going to call them the server, the
executor, and the display. The server is where the information you are
getting resides. The executor is where the WWW browser is running. The
display is where you are going to view the information. The confusion
stems from inadequately distinguishing between the executor and the
display.

The connection between the executor and the display is nobodies
business but their own. It could be a serial line over which you're
passing ASCII, an ethernet over which X packets are flowing, an ISDN
line that you're sending Group 4 faxs over, or a piece of video ram in
the same machine. It doesn't really make any difference to whether or
not you can run a WWW browser with those two, so long as one has been
written to display using the API in question.

Now, the connection between the server and executor is everybodies
business, because everybody needs to connect to the server. What is
required is that a TCP connection is opened to the server, and that
packets pass between the executor and server properly. Whether they
get translated into something else between the executor and the server
is immaterial.

So what kind of configurations can we build out of this?

Well, the original Mosaic configuration probably had the executor and
display on the same Unix box, using X protocols to talk to each other.

Splitting those two using using X protocols is pretty trivial. They
could use Xremote to talk over a serial line, or IP protocols to talk
over an ethernet, or over a serial line running SLIP or PPP.

If you have a vt100 display, you could use lynx or emacs-w3, with a
serial line between the executor and the display.

To get really arcane, you could have the executor using some protocol
other than TCP to talk to a gateway that uses TCP to talk to the
server. This is what term and dnet do. The gateway runs on a standard
Unix shell account, and the (modified) browsers use those protocols
over a serial line to the gateway. Both of these protocols multiplex
streams over that serial line.

Finally, you can use this kind of unix gateway/mux setup with SLIP as
the intermediate protocol. This has the advantage that your browsers
don't have to be modified to the API for that protocol, but can use
standard IP APIs. This is what TIA does.

The answer to the question "Will a WWW browser run on Unix" is pretty
clearly yes. The answer to the question "Does it require an IP
connection" is no. The executor requires some way of making an IP
connection to the server to fetch data, but that doesn't have to be IP
on the executor. How it talks to the display depends on the WWW
browser.

One final note - if the server and executor are on the same box, you
don't have to use a TCP connection to the server. But then, it's more
like a Machine Narrow Web instead of a World Wide Web.

Now that everybody is thoroughly confused, maybe this can end...

	<mike

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 10:19:54 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: 1 host, 2 cards, same address?

In article <330d24$98o@hacgate2.hac.com> rbrandt@hac.com (Richard Brandt) writes:
>This isn't in the FAQ and although I've seen it addressed here I don't think
>I've gotten the answer I need.  For various applications I've run across, for
>redundancy or for load sharing, it seems to be a good idea to have a host that
>has 2 interfaces onto the same ethernet or FDDI segment.  That would imply
>that the network portion of the IP address for both interfaces would be the
>same while the host portion could be different.  Now it seems that I've heard
>that at least an older version of SunOS wouldn't let you do that.  I've heard
>different stories from different persons on whether that is still true for Sun
>and all the other vendors (IBM, HP, DEC, SGI).  What I would like is to hear
>from the net is if someone has done this and what if any problems they've had.
>If it can be done (and it may be an OS by OS case) how is 1 interface chosen
>over another?  The source code for IP seems to take the target IP address and
>strip the network portion and then do a table match on the interface cards.
>That would imply the same interface is chosen first all the time.

  For an "interesting" discussion of this see RFC 1122, the
  requirements for internet hosts, communications layers.

  It discusses the strong and weak models of routing and how the two
  models differ in deciding which IP address to place in outbound
  packets and which interface to choose.  IMHO this is an area that
  needs a bit more work, as the ability to loadshare across virtual
  routes and link groups could indeed be nice for the larger systems
  able to easily saturate links under the old "one subnet, one host
  address" model.  I've seen several proprietary implementations
  which use multicast addresses at the MAC layer to implement a
  virtual Internet address which really exists on multiple links.
  Don't really know if there is an RFC which provides a good
  interoperable implementable model of this yet or not....
  
  Some implementations of the Lachman stack do real quaint things
  where packets may come in on multiple MAC addresses but will only
  go out on one.    



-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 00:14:28 GMT
From:      jblaine@ciesin.org (Jeff Blaine)
To:        comp.protocols.tcp-ip
Subject:   Re: 1 host, 2 cards, same address?

In article <330d24$98o@hacgate2.hac.com> rbrandt@hac.com (Richard Brandt) writes:
>This isn't in the FAQ and although I've seen it addressed here I don't think
>I've gotten the answer I need.  For various applications I've run across, for
>redundancy or for load sharing, it seems to be a good idea to have a host that
>has 2 interfaces onto the same ethernet or FDDI segment.  That would imply
>that the network portion of the IP address for both interfaces would be the
>same while the host portion could be different.  Now it seems that I've heard

   What if you have an ethernet interface and a FDDI interface?  Surely
   these will not have the same net portion of their IP addresses.
   We have 2 multi-homed machines here, each with a Sun Lance Ethernet
   interface and Sun FDDI interface.  The ethernet interfaces are
   a.b.c.d while the FDDI interfaces are a.b.G.d, where G denotes
   our FDDI ring subnet.

>that at least an older version of SunOS wouldn't let you do that.  I've heard
>different stories from different persons on whether that is still true for Sun
>and all the other vendors (IBM, HP, DEC, SGI).  What I would like is to hear

   It works with SunOS 4.1.3 at least.

>from the net is if someone has done this and what if any problems they've had.

   You'll need to be careful DNS wise.  In general, you'll want to
   define separate hostnames for each interface.  I believe the
   O'Reilly DNS and BIND book says you can do something like:

   hostname    IN    A  xxx.xxx.bbb.aaa
                        xxx.xxx.yyy.zzz

   (this assumes a class C net above)

   We've found the easiest workable solution to be to define
   hostname and hostnamef (FDDI) and have their respective
   addresses defined separately in our DNS tables.

   You'll know soon after you've configured things if they're
   working properly -- if your r-commands and remote connections
   start getting hosed, you'll know something's wrong.
   (i.e. the arp cache on machine X says hostname has IP address
   a.b.c.d, yet you just connected to machine X from hostname
   and the packets went out the other interface with IP address
   a.b.e.f).  Honk.

>If it can be done (and it may be an OS by OS case) how is 1 interface chosen
>over another?  The source code for IP seems to take the target IP address and
>strip the network portion and then do a table match on the interface cards.
>That would imply the same interface is chosen first all the time.
>
>The other question, if this can be done, is what happens if you get an IP 
>broadcast?  Wouldn't 2 copies of the same packet go up the stack? 

   It depends on what type of broadcast you're talking about.  If
   you're doing a subnet-directed broadcast, then only the interface
   connected directly to that subnet will receive the broadcast
   packet(s).  If you're talking about an entire net broadcast,
   then sure, both interfaces will receive the packet(s) as I
   understand it.

>
>Thanks!
>
>--
>Richard L. Brandt
>Hughes Aircraft Company
>(303) 344-6586
>rbrandt@redwood.hac.com


-- 

Jeff Blaine         le0 ni0 et0 en0 ie0 lan0 de0 ec0 ex0 il0 ix0 enet0
CIESIN Operations   Standardize UNIX

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 01:55:38 GMT
From:      glenc@coho.halcyon.com (Glen Clark)
To:        comp.protocols.tcp-ip
Subject:   TNGLASS for MSFT TCP/IP ...

I have a large customer who is looking ro NTGLASS 
capabilities on top of Microsoft's TCP/IP protocol stacks.

Any help would be apprecited.

Sincerely,
Glen Clark
ESDL, Inc.



-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 01:57:31 GMT
From:      glenc@coho.halcyon.com (Glen Clark)
To:        comp.protocols.tcp-ip
Subject:   TNGLASS RFP or Specification ....

Is there an RFP or public specification for the TNGlASS
facility found in some TCP/IP protocol stacks?

Sincerely,

Glen Clark
ESDL, Inc.


-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 07:11:55 GMT
From:      mcox@osaiphp1.osa.csi.itg.telecom.com.au (Michael Cox)
To:        comp.protocols.tcp-ip
Subject:   Linux and SLIP

According to the Linux HOW-TO, you need disk set N. I am told it has both
SLIP and PPP.
The Linux FAQ's are from sunsite.unc.edu:/pub/Linux/docs
Hope this helps.

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 1994 08:31:21 +0000
From:      nick@tweed.demon.co.uk (Nick Felisiak)
To:        comp.unix.unixware,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Q: LLC2 interfacing/routing?

In article <32r23n$r1p@crl2.crl.com> cgi@crl.com (Paul Smith) writes:
>Anybody have any idea whether UnixWare's TCP/IP stack can be run over
>LLC2 over the LAN to a remote X.25 server??
>
>Even if U.W. does not have this facility that I believe is configured over
>the DLPI ethernet driver as another protocol, with IP on top of LLC2, I'm
>looking for "simple" how does this work, what can you do with it doc or
>literature.

The normal way of running IP over LLC on a LAN is to use LLC1. This is the
format used by Token Ring, FDDI, etc.  While there is a defined format
for this on Ethernet, virtually no-one uses it.  HP did once (and may
still do on some non-Unix kit?).

>The solution I seek is: an X.25 API (JAXI, SPI or similar) available on a 
>host box (U.W., Sun, OSF1) to interface an X.25 server box on the LAN
>as if those X.25 services where local to the box 
>(sync card, x.25 driver etc).
>

I think this is a different question.  If I understand you correctly, what
you want is an 'X.25 server'.  Hosts on your network would connect to the
server and be in a position to apparently directly establish X.25 VC's.
This is a 'classic' client-server problem.  Cast all thoughts of LLC2 from
your mind :-).

When at Spider, I roughed-out a design for such a capability.  There are
two approaches for Spider X.25, which is streams based. Two approaches
were looked at.  The first was to implement a 'remote streams' driver.
The hosts would open the X.25 pseudo-device, which would actually establish
a TCP session to the server, where a 'real' X.25 stream was opened.
Messages are then carried transparently (to the application) from the
pseudo-device to the 'real' X.25 driver.  This approach has the advantage
of tranparency for the applications - they don't need to know whether
they actually have X.25 hardware.

The second approach was to avoid system calls in the client hosts, and use
RPC to access the server.  This allows an entirely user-level solution at
the expense of a different programming interface.

There are, of course, issues of addressing and so on which must be resolved
before any sort of 'server' solution can be implemented - these are
application dependent.

>Any help would be appreciated.  It seems, my confusion of how all this
>plugs together has been stuborn for me and others to erradicate....
>

Hope this helps

Nick
-- 
Nick Felisiak						nick@tweed.demon.co.uk
Copestone Research Ltd					+44 721 730 288
Eddleston by Peebles, Scotland
	   Networking, Unix, and Embedded Systems Consulting

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 16:17:11 -0400
From:      gwright@connix.com (Gary Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksum

>See RFC's 1071 and 1141.

Note, RFC 1141 has been updated by RFC 1624.

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 1994 10:31:19 GMT
From:      new@thrush.cfmu.eurocontrol.be (Dennis Newport)
To:        comp.protocols.tcp-ip
Subject:   RIP

We have a dual LAN set-up where there is a range of workstations and servers all with interfaces
to both LANs. There are also a couple of routers involved but I digress.

We use RIP (our gated.conf is pretty straightforward). If we remove the primary LAN connection
to a station then after 5 minutes (the delay and garbage collection timers totalled in RIP) the 
station uses the backup (secondary) LAN just as we want but the server that we want to talk to
doesn't see that the station is on the secondary LAN because the primary subnet is still up and
running, it is only the one station that has gone.

Now this may seem a stupid question, but is there any way for us to configure via gated.conf or
otherwise so that we can manage to reach stations that have switched LAN (and therefore IP address).

I would be grateful for any input (and so would my station !!!).




-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 19:15:37 -0400
From:      robelr@indiana.edu (Allen Robel)
To:        news.announce.newgroups,news.groups,comp.dcom.cell-relay,comp.dcom.isdn,comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.dcom.lans.misc,comp.protocols.tcp-ip,bit.listserv.novell
Subject:   2nd RFD comp.dcom.frame-relay

Hi,

I have received several direct correspondences indicating support for a
new newsgroup catering to frame-relay.  I was absent during much of the
discussion period though due to a family illness, so if anyone is
adamantly opposed to the creation of this newsgroup, please speak up
now.

Likewise, if there were suggestions for modification of the charter,
please forward them again.

Barring widespread opposition, I propose that we move to begin the
voting period on 8/21/94 and let it run till 9/21/94.  As mentioned
earlier, I will defer to the good folks at Qualcomm to handle the
vote. The CFV will be sent to the newsgroups listed below.  A second
CFV will be sent approximately halfway through the voting period (the
5th or 6th of September).

2nd REQUEST FOR DISCUSSION

NEWSGROUP: comp.dcom.frame-relay

UNMODERATED

Crossposted to:
news.groups
news.announce.newgroups
comp.dcom.cell-relay
comp.dcom.isdn
comp.dcom.lans.ethernet
comp.dcom.lans.fddi
comp.dcom.lans.misc
comp.protocols.tcp-ip
bit.listserv.novell

Given that Frame Relay is beginning to emerge as a mainstream WAN
service, and given that discussions of Frame Relay technology are
appearing with increasing frequency on other newsgroups such as
comp.dcom.cell-relay, perhaps now is the time to create a newsgroup
to provide a home for this topic.  Below is a draft charter, written
by Tom Jones, ex-chair of the Frame Relay Forum and continuing
proponent of Frame Relay services and technologies.  It is intended
as a starting point for discussion over the next month as to what
shape a Frame Relay newsgroup might take. Comments are welcome and
encouraged.

As per Usenet "policy"/tradition, the following timeline will be
adhered to:

7/21/94 - 8/21/94
Discussion period

8/21/94 - ~9/21/94
Voting (if it is generally agreed that this group would be a Good
Thing).

We will defer to the Usenet Volunteer Votetakers at Qualcomm to setup
and conduct the vote.

Below is the proposed charter.  The Followup-To: field has been set to
news.groups.  Please direct all comments concerning this Request for
Discussion there.

DRAFT CHARTER:

To provide a mechanism for the discussion of issues related to the
technology and application of frame relay in communications networks.

Topics expected to be discussed include (but are not limited to) the
following examples:

- frame relay standards and proposed standards
- applications of frame relay
- user experiences with frame relay
- relationship and comparison of frame relay to other technologies,
  including asynchronous transfer mode (ATM), cell relay, SMDS, 
  X.25 packet switching, IP routing, ISDN, Broadband ISDN, etc.
- announcements of conferences, seminars, etc., related to frame relay
- news of the availability of frame relay products or services
- testing and interoperability of frame relay
- information related to performance and implementation of frame relay
- research findings
- activities of The Frame Relay Forum and other similar organizations 
  with activities related to frame relay
- sources of additional information regarding frame relay

This newsgroup is not intended to be a forum in which standards are
developed, although it may be expected to relate news pertaining to
standards and to the progress of recognized standards bodies.

regards,
-- 
Allen Robel                        Internet: robelr@indiana.edu
Network Engineer                   voice:    (812)855-0962
Indiana University                 FAX:      (812)855-8299

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 19:22:04 -0400
From:      rdippold@qualcomm.com (Ron "Asbestos" Dippold)
To:        news.announce.newgroups,news.groups,comp.protocols.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.networking.tcp-ip
Subject:   RESULT: comp.protocols.smb passes 232:20

                                    RESULT
              unmoderated group comp.protocols.smb passes 232:20

There were 232 YES votes and 20 NO votes, for a total of 252 valid votes. 
There was 1 abstain and 1 invalid ballot.

For group passage, YES votes must be at least 2/3 of all valid (YES and NO)
votes.   There also must be at least 100 more YES votes than NO votes. 

There is a five day discussion period after these results are posted.  If no
serious allegations of voting irregularities are raised, the moderator of
news.announce.newgroups will create the group shortly thereafter.


Newsgroups line:
comp.protocols.smb      SMB file sharing protocol and Samba SMB server/client.

This vote is being conducted by a neutral third party.  For voting
questions only contact rdippold@qualcomm.com.  For questions about the
proposed group contact Tom Haapanen <tomh@metrics.com>.


CHARTER

comp.protocols.smb is for discussions about the use of the SMB
protocol, its applications and compatability, and for the discussions
about SMB-based server and client software, such as Samba.

There is currently no Usenet newsgroup for discussions about the use
of the SMB networking protocol, or for discussions about SMB-based
software packages.  This protocol is increasing in popularity and
deserves a proper home.

The SMB protocol is used by software such as Microsoft LAN Manager,
IBM LAN Server, Windows for Workgroups, Windows NT and the upcoming
new version of Windows, "Chicago."  It provides services for name
services, disk sharing, printer sharing and browsing.  It can run on
top of Netbeui, IPX/SPX, and, more importantly, TCP/IP, making it a
versatile protocol with capabilities exceeding those of NFS.

It has been argued that SMB is not a protocol; however, the official
SMB specifications (available by FTP from ftp.microsoft.com) call it
"SMB FILE SHARING PROTOCOL".  This certainly makes it as much of a
protocol as, say, NFS (in comp.protocols.nfs).

There is currently available a free (using the GNU Public License)
implementation of and SMB server and client, Samba, developed by
Andrew Tridgell at the Australian National University in Canberra,
Australia.  With the added availability of the free TCP/IP protocol
stack (for Windows) and client software (for MS-DOS and OS/2) from
Microsoft, SMB becomes a versatile yet inexpensive alternative to NFS
for Unix/Windows/MS-DOS internetworking.

There is now in existence a mailing list for Samba and SMB
discussions, hosted at the Australian National University.  This
mailing list has been growing in both membership and traffic, and the
time has come to make the transition into a newsgroup.  Currently the
mailing list has over 400 subscribers (not including those served by
remote mail exploders), with increasingly heavy traffic.  The Samba
ftp site also gets 200-400 connections per week.

While Samba is expected to be the most popular topic of discussion,
all other SMB-related discussions will also be welcome.

comp.protocols.smb Final Vote Ack

Voted Yes
------------------------------------------------------------------------------
adrian@hippocrates.family.med.ualberta.ca                         Adrian Smith
af576@freenet.carleton.ca                                      Alexandre Vovan
afmoraes@if.usp.br                                                            
ag129@ucs.cam.ac.uk                                             Alasdair Grant
ana@tele.nokia.fi                                           Antti V{h{lummukka
Andrew.Tridgell@cs.anu.edu.au                                  Andrew.Tridgell
andrew_c@oldham.gpsemi.COM                                          Andrew Cox
ARASSEL@restena.lu                                      Alain RASSEL 5313-2121
Arthur.Chance@Smallworld.co.uk                                   Arthur Chance
b4imrwlb@cpc41.cpc.usace.army.mil                                   Lynn Bilbo
baeder@Cadence.COM                                                Scott Baeder
barnes@escher.gatwick.Geco-Prakla.slb.com                         Simon Barnes
barnett@sunrock.tamu.edu                                        Ashley Barnett
ben@stuyts.nl                                                       Ben Stuyts
benji@athena.com                                                Benjamin Cline
bernie@netgain.com                                                 Bernie Mans
billiotte@cgi.ensmp.fr                                          Joel BILLIOTTE
bjv@herbison.com                                                 B.J. Herbison
bmw@isgtec.com                                                 Bruce M. Walker
bob.baggerman@gtri.gatech.edu                                    Bob Baggerman
bob@fisher.cs.depaul.edu                                            Bob Fisher
bornet@cervin.idiap.ch                                                       )
botman@mcgi.com                                                    Rick Botman
bottasini@cesi.it                                           Giuseppe Bottasini
brad@cac.washington.edu                                             Brad Greer
bruce@pixar.com                                                   Bruce Perens
Bryan@Novell.COM                                                 Bryan Cardoza
buravand@norma.cad.cea.fr                                        Yves Buravand
bwillems@dogbert.dac.neu.edu                                   Balam Willemsen
cap@hces.com                                                      Simon Casady
capriott@settimo.italtel.it                                                   
carl@asi.com                                                        Carl Ellis
Carlos.Picoto@di.fc.ul.pt                                        Carlos Picoto
casteels@uia.ac.be                                               Paul.Casteels
ccms@utcc.utoronto.ca                                        Erik Ivanenki/0/o
CCMSHIU@usthk.ust.hk    Michael Shiu, HKUST, (852)358-6205, ccmshiu@usthk.ust.
ccult1!dehartog@relay.NL.net                                                  
ceh@eng.cam.ac.uk                                              Charles Hawkins
charlie@edina.demon.co.uk                                       Charlie Hussey
charlieb@budge.apana.org.au                                                   
chris@cnawan.demon.co.uk                                           Chris Owens
cjw@actrix.gen.nz                                                Chris Woodrow
clg@research.canon.oz.au                                      Cassandra Gordon
clstampe@mailbox.syr.edu                                         Chris Stamper
Colin.Dean@Smallworld.co.uk                                         Colin Dean
cooper@prepress.pps.com                                                       
corey@bbs.xnet.com                                               Corey Sweeney
cro@socrates.ed.asu.edu                                           C. R. Oldham
cs002@csalpha.unomaha.edu                   Stan Wileman, UNO Computer Science
curt@ltpsun.gsfc.nasa.gov                                          Curt Tilmes
cvaleze@huelen.ing.puc.cl                                    Claudio Valeze J.
cward@Think.COM                                               Christopher Ward
daavid@tusc.com.au                                             Daavid Turnbull
Daniel.Grandjean@dgr.epfl.ch                                  Daniel Grandjean
daniel@ing.puc.cl                                            Daniel Hirschberg
davem@shell.portal.com                                       David Mollerstuen
David.Richards@ccc.govt.nz                                      David Richards
ddambros@nyx10.cs.du.edu                                                   Dan
ddavis@osiris.cso.uiuc.edu                                          Dave Davis
df@eyrie.demon.co.uk                                              Derek Fawcus
DIDIER@lmb1.rug.ac.be                                             Didier Moens
dmneal@waikato.ac.nz                                                          
doug@mcs.com                                                    Douglas Harvey
dupuis@lei.ucl.ac.be                                          Pascal A. Dupuis
eenest@sovcom.kiae.su                                     Eugene E. Nesterenko
ekaftan@ing.puc.cl                                           Eduardo Kaftanski
errath@balu.kfunigraz.ac.at                                  Maximilian Errath
esa@cyclone.atl.ga.us                                                Esa Ahola
evas@cs.few.eur.nl                                           Eelco van Asperen
f1rederc@iia.org                                               Chris Frederick
feichtin@informatik.uni-kl.de                                                 
fergus@lincoln.gpsemi.COM                                     Fergus McMenemie
fn@graf.polymtl.ca                                            Francois Normant
fw@world.std.com                                            forrest d whitcher
gaffney@protein.med.uvm.edu                                     Donald Gaffney
gallion@acmelabs.uhc.asu.edu                                    Travis Gallion
gerle@kreta.informatik.uni-dortmund.de                           Stephan Gerle
glennr@netcom.com                                                  Glenn Rysko
gray@cac.washington.edu                                             Terry Gray
groot@world.std.com                                              Groot Gregory
hadfield@storm.greta.cri.nz                                      Mark Hadfield
hall@med.ucalgary.ca                                                 Doug Hall
HANNU@estib.ee                                                                
harish@csah.com                                                  Harish Pillay
harro@maths.su.oz.au                                           Daniel Harrison
hart@eppie.apana.org.au                                             Leigh Hart
heilbron@ISAR.MUC.DE                                       Stephen Heilbronner
hench@cae.uwm.edu                                                   Mike Hench
horn@mickey.jsc.nasa.gov                                                      
hpa@nwu.edu                                                     H. Peter Anvin
htescc@cix.compulink.co.uk                          East Sussex County Council
iay@threel.co.uk                                                   Ian A Young
ibanks!peter@uunet.uu.net                                        Peter Hoffman
ictinus@lake.canberra.edu.au                                    Paul  Blackman
ih@doc.ic.ac.uk                                                    Ian Harries
Ilkka.Tuuli@vtt.fi                                                 Ilkka Tuuli
J.K.Field@ecs.soton.ac.uk                                         Julian Field
jaenicke@emserver.ee.TU-Berlin.DE                                Lutz Jaenicke
JEFROB@delphi.com                                                             
jimw@PE-Nelson.COM                                                    Jim Watt
jm1688@spindletop.tamu.edu                                                    
jmdaluz@kquest.com                                               Jose M. daLuz
jmi@csd.cri.dk                                                      John Mills
jms@esu.edu                                                       James Strain
Joel.Crisp@bristol.ac.uk                                          Joel A Crisp
john@amanda.hacktic.nl                                            John Stewart
john@micros.com                                                     John Owens
Jon.Thackray@froggy.demon.co.uk                                   Jon Thackray
Jonas.Andreasson@dacapo.se                                    Jonas Andreasson
joshia@cranium.com.msu.edu                                    Amaresh R. Joshi
jperches@netcom.com                                                Joe Perches
jpeterse@che.wsu.edu                                         James N. Petersen
jr@eecws5.tuwien.ac.at                                          Josef Redinger
jrc@apollo.jgvandyke.com                                             JR Conlin
jschief@finbol.toppoint.de                                                    
jschoi@cad2.seodu.co.kr                                           Choi Jaeseon
Jurg.Umhang@mo49.asb.admin.ch                                                 
jurgen.baier@dns1.cim.ch                                         Juergen Baier
kahuna@fc.net                                                      Max Mednick
Karl.Auer@anu.edu.au                                                 Karl Auer
keung@olisc.air.org                                             Tang Tat Keung
kfan@griffin.com                                                   Frankie Fan
ki1!gnu%bmwsys.uucp@Germany.EU.net                                gnu Software
kimbler@eng.clemson.edu                                          D. L. Kimbler
kluge@mineral.geowiss.ba-freiberg.d400.de                        Andreas Kluge
krli@ppvlu.ericsson.se                                          Kristofer Liew
L15D@ZFN.UNI-BREMEN.DE                                        Martin Schroeder
lane@artisoft.com                                                             
larry@witch.mitra.com                                         Larry Williamson
lehnert@kapsch.co.at                                            Lehnert Rudolf
lenneis@statrix2.wu-wien.ac.at                                   Joerg Lenneis
linauer@edvz.tuwien.ac.at                                          Udo Linauer
linvjw@aur.alcatel.com                                           John Linville
lneves@inescc.pt                                       Luis Miguel Pires Neves
lpc@solomon.technet.sg                                            Michael Chua
magnus@axiom.se                                            Erik Magnus Hulthen
martikka@tele.nokia.fi                                          Hannu Martikka
mbm@dsbc.icl.co.uk                                          Malcolm Mladenovic
mcochran@wellfleet.com                                            Marc Cochran
mcs@molson.ho.att.com                                             Mike Stanton
MHT@nuclint.nl                                                  Marc ter Horst
Michel.Debar@fundp.ac.be                                          Michel Debar
middelin@calvin.iaf.nl                              Jeanette Pauline Middelink
mike@charnock.demon.co.uk                                                     
mike@planet8.sp.paramax.com                                 Michael W. Grenier
mjr@tis.com                                                     Marcus J Ranum
ml@cvdev.rochester.edu                                        Mark R. Levinson
mloewen@cpumagic.scol.pa.us                                  Michael C. Loewen
morgan_t@sparky.navsea.navy.mil                               Thomas P. Morgan
muir@idiom.berkeley.ca.us                                  David Muir Sharnoff
murf@perftech.com                                                  John Murphy
myles@platypus.murdoch.edu.au                                 Myles Kennington
nca@lep-philips.fr                                          Nicos Achilleoudis
ngps@np.ac.sg                                                   Ng Pheng Siong
njw@cpsg.com.au                                                      Neil Webb
nmorgan@wintermute.win.net                                      Noel C. Morgan
okir@monad.swb.de                                                   Olaf Kirch
orser@fubar.cs.montana.edu                                          Gary Orser
osyjm@pdq.coe.montana.edu                                /usr/spool/mail/osyjm
PapaM@wet.sbi.com                               Papatheofanous, Manos    (BTO)
pappinm@ayr_srv2.nth.dpi.qld.gov.au                                Mark Pappin
patrick@gopher.dosli.govt.nz                                           Patrick
paula@netcom.com                                                   Paul Ananth
pdcruze@orac.iinet.com.au                                      Patrick D'Cruze
pe1chl@rabo.nl                                                                
pep@wicked.demon.co.uk                                             Phil Packer
peter.owen@anu.edu.au                                               Peter Owen
peters@calvin.iaf.nl                                              Peter Peters
phil@hands.com                                                      Phil Hands
pim@cti-software.nl                                             Pim Zandbergen
pragma@login.dkuug.dk                                           Michael Larsen
psyclass@arts.adelaide.edu.au                                      Bob Willson
quinn@phoenix.Princeton.EDU                                   Michael J. Quinn
raarts@netland.nl                                                     Ron Arts
rafi@tavor.openu.ac.il                                           Rafi Sadowsky
rama@i88.isc.com                                          Sudhakar Ramakrishna
randy@chinet.chinet.com                                            Randy Suess
raphael@research.canon.oz.au                                    Andrew Raphael
rath@centre.saclay.cea.fr                                             V.KOUNDY
rbp@netcom.com                                                      Rob Philip
rdb@cocamrd.mel.cocam.oz.au                                       Rodney Brown
reh@nomos.com                                                       Rich Huber
remme@vortice.stortek.com                                       Steve K. Remme
RFowler@spmc-server.jpl.nasa.gov                  Fowler, Robert A. (SysAdmin)
Rich-Hoesly@uai.com                                                           
richard.spitz@ana.med.uni-muenchen.de                            Richard Spitz
rick@bcm.tmc.edu                                             Richard H. Miller
rob@eats.com                                                      Rob Newberry
rob@gec-mi-at.co.uk                                               Rob Matheson
robertk@lotatg.lotus.com                                      Robert Krajewski
rudy.benz@gtri.gatech.edu                                            Rudy Benz
rufinus@cae.wisc.edu                                                          
sailer@sun10.sep.bnl.gov                                            Tim Sailer
sartin@pencom.com                                                   Rob Sartin
sarum@monosys.com                                     David Allan Finch - work
schoneve@fwi.uva.nl                                           Arjen Schoneveld
scott@asl.cr.usgs.gov                                            Scott Halbert
seodu@soback.hana.nm.kr                                            Seodu Logic
serg@energo.pssr.e-burg.su                                   Sergey Drazhnikov
sg84p772@dunx1.ocs.drexel.edu                                   Darin M Strait
sherwood@esu.edu                                                Brian Sherwood
skl@Connectivity.com                                                Samuel Lam
small@netcom.com                                                   Kevin Small
SMARTIN@gar.uhc.com                                       Stephen J. Martineau
smith@sleep.ee.ufl.edu                                           Jack R. Smith
sr1@irz301.inf.tu-dresden.de                                      Sven Rudolph
sreiz@aie.nl                                                       Steven Reiz
sseaton@iise.csiro.au                                             Scott Seaton
steve@qv3donald.LeidenUniv.nl                                 Stephen C. Steel
steve@trinidad.ISI-AutoNet1.Com                                   Pavlov's Cat
sxjcb@alaska.edu                                                   Jay Beavers
tcleamy@ucdavis.edu                                                           
terryt@ren.pc.athabascau.ca                                       Terry Tanski
tfl@psp.co.uk                                                     Thomas F Lee
tgc@world.std.com                                                 Terry Carlin
thorsten@radar.sauerland.de                                      Thorsten Kitz
tjfiske@qualcomm.com                                                T.J. Fiske
tmg@wg.saar.de                                           Tilman Mueller-Gerbes
tomc@osi.curtin.edu.au                                             Tom Crawley
toobii@elixir.e.kth.se                                          Torbjörn Lindh
tpepin@wdni.com                                                  Anthony Pepin
tsarna@endicor.com                                                    Ty Sarna
tsukada@gaken.dnp.co.jp                                          TSUKADA Seiji
tucke_m@admiral.co.uk                                              Mark Tucker
vijay@hi.com                                                       Vijay Kumar
wenwei@cbis.ECE.Drexel.EDU                                         Wenwei Qiao
wiljo@cls.net                                                     Wiljo Heinen
wnp@aaf.alcatel.at                                                   Wolf Paul
Xavier.Redon@prism.uvsq.fr                                                    
yadallee@GALlif.ERsys.EDmonTON.Ab.cA                     Dave Shariff Yadallee
yubo@bnlux1.bnl.gov                                                      Bo YU
zco9atrl@slate.Mines.Colorado.EDU                                             

Voted No
------------------------------------------------------------------------------
antersbe@informatik.tu-muenchen.de                         Stefan Antersberger
crouchkp@flidh102.delcoelect.com                                              
dacey@crl.com                                                   Peter Campbell
ewl@sacco.cs.nyu.edu                                            Emery Lapinski
fsspr@camelot.acf-lab.alaska.edu                                  Sean P. Ryan
grohol@alpha.acast.nova.edu                                        John Grohol
jeffg@loki.engr.sgi.com                                         Jeff C. Glover
jfortt@dorsai.dorsai.org                                          Joseph_Fortt
jrm@globalvillag.com                                     John R. MacWilliamson
lantz@halcyon.com                                                Lantz Rowland
laurion_burchall@il.us.swissbank.com                          Laurion Burchall
mmt@RedBrick.COM                                          Maxime Taksar KC6ZPS
netcon2@hpwin062.uksr.hp.com                                         Ian Spare
rew@moontarz.nuance.com                                           Ryan Waldron
sam@sun.tps.de                                                    Sassan Simai
siamak@kaiwan.com                                                Siamak Ansari
smarry@turing.toronto.edu                                         Smarasderagd
srogers@tad.eds.com                                               Steve Rogers
stainles@bga.com                                                  Dwight Brown
WARD@ernie.van.forintek.ca                                        Ward F. Bush

Abstained
------------------------------------------------------------------------------
carlson@cap.gwu.edu                                            Eric C. Carlson


Votes in error
------------------------------------------------------------------------------
root@budge.apana.org.au                                                   root
   ! Invalid address

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 1994 13:17:36 GMT
From:      gdouglas@world.std.com (Gordon L Douglass)
To:        comp.protocols.tcp-ip
Subject:   TCP ODI driver


	I am looking for an ODI driver that displays TCP packets over
	a LAN. I believe the name is on the lines of ephload???
	Does / Can anyone direct me to the location of this driver??


	Thanks!

	gordon@world.std.com


 Pentiums melt in your PC, not in your hand.


-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 1994 16:29:02 GMT
From:      kh@world.std.com (Kurt Hackenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksum

jsb@speedy.inri.com (J. Spencer Brown) writes:

>Does anyone out there know what algorithm TCP uses to compute its
>checksum.  What data does this include?  Any help would be 
>appreciated.


See RFC's 1071 and 1141.

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 16:42:11 +0100
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

In article <MICHAELV.94Aug17014811@mindbender.headcandy.com>,
	michaelv@MindBender.HeadCandy.com (Michael L. VanLoon) writes:
>And, I also have to take to task "PC/Unix".  The freeware PC/unix
>"market" is where PPP is the most alive, from what I've noticed.

Most alive yes, but ...

>The big commercial workstation Unix companies (DEC, Sun, HP, ...) haven't
>done much to support PPP that I've noticed.

Sun have been shipping PPP with their current OS for almost a year now.
So does that count as not doing much to support PPP?
(Ok, so you have apply a patch before it works)

And you can PPP for a lot of platforms from folks like MST and others.

Cheers,
-- 
Ian 'Vato' Dickinson [ID17]                                   Kibo bait :-)
cudep@csv.warwick.ac.uk  ...!uknet!warwick!cudep           vato@spuddy.uucp
           MIME mail welcome - don't send me no steenkin' X.400
      Click <A HREF="http://www.csv.warwick.ac.uk/~cudep/">here</A>.

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 1994 20:40:33 GMT
From:      cappisk@cuug.ab.ca (Kevin Cappis 283-6333)
To:        comp.protocols.tcp-ip
Subject:   assigning tcp ports


Hello All,

   I have a question concerning tcp port numbers. I have a customer who
has a Tandem unix host connecting to an ip network over ethernet. We want
to be able to connect to a specific tcp port on the Tandem host for a Telnet
session. We can get in using the standard port 23, but when we try to use
a different port number (ie. 200). We can't connect into the host. We have
made changes to the etc/network services file, (ie. 200 telnet   /tcp)
to assign telnet to tcp port 200. I am sure there is a way to get telnet
assined and working on tcp port 200, but I'm no Unix whiz. If anyone knows
anything about assigning tcp ports on a Unix host, especially if it's a
Tandem, I could sure use the help.

   By the way, the calls are all coming into the Tandem host from the 
network

Cheers, Kevin

 

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 20:54:50 GMT
From:      jdc@inca.cs.wayne.edu (Jon Cardwell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.apps,comp.os.ms-windows.apps.misc,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.win32,comp.os.ms-windows.programmer.networks,comp.os.ms-windows.networking.misc
Subject:   Canned API for SLIP/PPP dialup scripting, Modem Config., etc?

I'm thinking about putting together a network application
a part of which is similar to the part of Tatam's Windows Trumpet
that establishes a SLIP/PPP conection over a modem. To save
some time, I was wondering if there is any kind of "canned"
API for:

	1) Managing a modem/script configuration file (like the
	   protocol.ini and slip.ini files with Netmanage Chameleon)

	2) Doing the actual scripting (waiting for input strings,
	   doing delays, waiting for modem control signals, sending
	   output strings, getting IP addresses, etc)

	3) Doing the modem communications for initialization, settings,
	   dialing, etc.

Every slip/ppp package that I've seen seems to have an ad-hoc
approach to this, some fancier than others...

--Jon Cardwell
Wayne State University


-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 21:26:43 GMT
From:      bneill@cc.dixie.edu (Brandon Neill)
To:        comp.protocols.tcp-ip
Subject:   HELP netware and tcpip

I am try to connect a novell network running netware v3.12 to the internet.
Could someone reccomend a software package (public or commercial) that can
do this.  We already have an internet connection and the network is setup.
We just need to connect the two. Any tips or information would be helpful. 
Thanks.
						brandon

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      19 Aug 1994 22:09:22 GMT
From:      conrad@hathi.informatik.rwth-aachen.de (Christoph Conrad)
To:        comp.protocols.tcp-ip
Subject:   Books&Sources TCP/UDP Programming

Hello,

are there any good books about TCP/UDP--programming?
I am looking also for sources in this topic and hints how to
implement intelligent client/server concepts with TCP/UDP,
especially recovery strategies (client crashes, server hangs etc.).

thank you,
Christoph.
-- 
conrad@pool.informatik.rwth-aachen.de

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Aug 1994 23:45:53 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksum

In article <3309i7$vl@speedy.inri.com> jsb@speedy.inri.com (J. Spencer Brown) writes:
>Does anyone out there know what algorithm TCP uses to compute its
>checksum.  What data does this include?  Any help would be 
>appreciated.

[From RFC793]

  Checksum:  16 bits
 
    The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.  If a
    segment contains an odd number of header and text octets to be
    checksummed, the last octet is padded on the right with zeros to
    form a 16 bit word for checksum purposes.  The pad is not
    transmitted as part of the segment.  While computing the checksum,
    the checksum field itself is replaced with zeros.
 
    The checksum also covers a 96 bit pseudo header conceptually
    prefixed to the TCP header.  This pseudo header contains the Source
    Address, the Destination Address, the Protocol, and TCP length.
    This gives the TCP protection against misrouted segments.  This
    information is carried in the Internet Protocol and is transferred
    across the TCP/Network interface in the arguments or results of
    calls by the TCP on the IP.
 
                     +--------+--------+--------+--------+
                     |           Source Address          |
                     +--------+--------+--------+--------+
                     |         Destination Address       |
                     +--------+--------+--------+--------+
                     |  zero  |  PTCL  |    TCP Length   |
                     +--------+--------+--------+--------+

      The TCP Length is the TCP header length plus the data length in
      octets (this is not an explicitly transmitted quantity, but is
      computed), and it does not count the 12 octets of the pseudo
      header.

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1994 00:58:40 GMT
From:      klwhite@magnus.acs.ohio-state.edu (Kevin L White)
To:        comp.protocols.tcp-ip
Subject:   IPng information?

I am looking for information on the proposed IPng standard.  I read
the short FAQ here and have scanned the messages for about a week and
haven't seen anything.  Can anybody point me to information?  E-mail
me if you want and I will post a summary.

Thanks!

Kevin

-- 
Kevin White --- klwhite@magnus.acs.ohio-state.edu --- Finger for Pub PGP Key! 
"Where...the ENIAC is equipped with 18,000 vacuum tubes and weighs 30
tons, computers in the future may have 1,000 vacuum tubes and perhaps
weigh just 1-1/2 tons."           Popular Mechanics, March 1949

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1994 10:33:21 -0500
From:      mayojoh@ac.com (Jack Mayo)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <32s1o0$5m2@nic-nac.CSU.net> root@dolphin.csudh.edu (Jon Stevens) writes:
[chop chop]
>
>You are NOW adding that you would like to do it without slip or ppp...you 
>did not say that before...without slip or ppp or "direct ethernet" you 
>can't run any form of Mosaic (Mac,PC,X)...but you can easily run lynx on 
[deleted]

You mean you can't run Mosaic over UUCP!? Damn. I just got a new
2400 baud modem and I thought that would be enough!

ha.


-- 
mayojoh@ac.com	| Disclaimer: What I say isn't what they say.

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 1994 17:12:12 -0700
From:      llmccall@ccnet.com (Lindsay McCall)
To:        comp.protocols.tcp-ip
Subject:   Blocks of Multiple Class-C Addresses

Frequent readers of this newsgroup will recognize this text from an 
posting of mine earlier this week.  I'm blaming the lack of response I got 
on my poorly-crafted summary and giving the question another shot...

I am unclear what magic words to use on the Internic request form 
that will get me a nice, consecutive block of about eight class-C 
addresses.  Is there a separate form I need to use?  The form I submitted 
got me one class-C group although I asked for more than one.  
Incidentally, is there a way to return these addresses into the pool?  
Maybe it's ignorance or lack of imagination, but one isolated group of 
addresses doesn't seem much use if I really need more, and if they were 
grouped together, it seems like I could better control my need to apply 
routers in strategic places.  Can anybody help or direct me to a faq, RFC 
etc that's on point?

Thanks...

Yours in TCP/IP unsophistication,

Lindsay McCall
Morrison & Foerster



-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 94 15:07:18 GMT
From:      chrisc@fir.canberra.edu.au (Chris Chlap)
To:        comp.protocols.tcp-ip
Subject:   Re: Books&Sources TCP/UDP Programming

In <333aii$h3r@urmel.informatik.rwth-aachen.de> conrad@hathi.informatik.rwth-aachen.de (Christoph Conrad) writes:

>Hello,
 
>are there any good books about TCP/UDP--programming?
>I am looking also for sources in this topic and hints how to
>implement intelligent client/server concepts with TCP/UDP,
>especially recovery strategies (client crashes, server hangs etc.).
Two very good books are:
Comer and Stevens: Internetworking with TCP/IP Vol. 2 and 3.
(Prentice-Hall)
I believe a Solaris Version of Vol. 3 has just been published, but this
is a rumor only.
Of course, the old classic "UNIX Network Programming" by W. R. Stevens
is also highly recommended.
Viele Gruesse,
Christopher Chlap,
University of Canberra, Australia.
>thank you,
>Christoph.
>-- 
>conrad@pool.informatik.rwth-aachen.de

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Aug 1994 18:17:30 GMT
From:      longyear@netcom.com (Al Longyear)
To:        comp.protocols.tcp-ip
Subject:   Re: Books&Sources TCP/UDP Programming

conrad@hathi.informatik.rwth-aachen.de (Christoph Conrad) writes:

>are there any good books about TCP/UDP--programming?
>I am looking also for sources in this topic and hints how to
>implement intelligent client/server concepts with TCP/UDP,
>especially recovery strategies (client crashes, server hangs etc.).

Here are some that you may wish to consider.

"Unix Network Programming" by W. Richard Stevens; Prentice Hall 1990;
ISBN 0-13-949876-1

"TCP/IP Illustrated, Volume 1" by W. Richard Stevens; Addison-Wessley
1994; ISBN 0-201-63346-9

"Adventures in UNIX Network Applications Programming" by Bill Reiken
and Lyle Weiman; John Wiley & Sons 1992; ISBN 0-471-52858-7

"Internetworking with TCP/IP" Volume III, Client - Server programming
and Applications by Douglas E. Comer and David L. Stevens; Prentice
Hall 1993; ISBN 0-13-474222-2

(The last book, by Comer, comes in two flavors. The ISBN number refers
to the BSD sockets version. There is a similar volume III for TLI.)

There are many other good books on TCP/IP. However, these tend to
discuss client/server programming rather than administration,
applications, etc. The TCP/IP Illustrated first volume discusses the
protocols and goes slightly into applications programming. A second
volume is due in October from Addison Wessley. This will cover more in
the programming area than the first volume.

[p.s. I don't want any followup mail from publishers pushing their books.
Thanks.]

-- 
Al Longyear           longyear@netcom.com

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 94 16:51:36 EET
From:      jaakola@cc.helsinki.fi
To:        comp.protocols.tcp-ip
Subject:   AS/400+TCP/IP and lpr/lpd

Some questions about lpr/lpd and AS/400+TCP/IP (what a pity there's no
comp.os.os400 nor comp.sys.as400):

Is it possible to send ASCII files with normal pritable characters,
newlines and form feeds via lpr to an AS/400 running lpd? Do they print
correctly?

How about printing binary files on an AS/400 running lpd with a HP
laserjet?

Can a normal AS/400 application send print jobs to a queue which sends
the print jobs via lpr/lpd protocol to a UNIX machine to be printed?
--
Juhani Jaakola, jaakola@cc.helsinki.fi

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Aug 1994 00:57:43
From:      robpang@leland.stanford.edu (Robert Pang)
To:        comp.protocols.tcp-ip
Subject:   Re: Andrew File System

In article <1994Aug17.204319.17608@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>Newsgroups: comp.protocols.tcp-ip
>Path: nntp2.Stanford.EDU!headwall.Stanford.EDU!kithrup.com!news.cygnus.com!cambridge-news.cygnus.com!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!hpscit.sc.hp.com!news.dtc.hp.com!col.hp.com!csn!decwrl!hookup!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.
>td.umich.edu!uunet!news.nevada.edu!jimi!ftlofaro
>From: ftlofaro@unlv.edu (Frank Lofaro)
>Subject: Re: Andrew File System
>Message-ID: <1994Aug17.204319.17608@unlv.edu>
>Sender: news@unlv.edu (News User)
>Organization: University of Nevada, Las Vegas
>References: <CunDCI.Fw2@da_vinci.ecte.uswc.uswest.com>
>Date: Wed, 17 Aug 94 20:43:19 GMT
>Lines: 42


>In article <CunDCI.Fw2@da_vinci.ecte.uswc.uswest.com> steveTow@rainbow.ecte.uswc.uswest.com writes:
>>
>>I am looking for information on the Andrew File System...RFC's, specifications, 
>>vendors, etc.  Any pointers to electronic sources?  Any pointers to written 
>>experiences with AFS?
>>
>>Thank you...
>>
>>steveTow
 
>How about some personal experience with it?
 
>It is slow, unreliable, servers need to be restarted every week (!), 
>incompatible, proprietary, not available for many OS's (e.g. Linux), 
>un UN*X like (chmod doesn't work totally right!), no support for anything 
>except files, directories, and symlinks (_NO_ devices, sockets, fifos), 
>hardlinks can not be made from a file in one directory to anywhere outside 
>_that directory_, hard to administer, buggy (race conditions in servers 
>causing crashes and corruption, clients have been know to eat the AFS 
>initialization files on the workstation, AFS cache corruption causing 
>programs to stop working on a machine until root clears the cache [after 
>downing the machine of course], also _ONE_ bad packet once crashed a whole 
>university's AFS system, all clients paniced and rebooted.), no 
>source unless you really pay, non-redistributable, ugly, few people 
>know how to administer (unlike NFS!), etc
 
>AFS, just say NO!
 
>Kerberized NFS is much better (we run that here). I'd sell my soul to get 
>KNFS if I was still stuck with AFS.
 
>If you insist on AFS, Transarc (transarc.com) is the source.
 
>They are in Pittsburgh, PA.
 
>But even they are dumping AFS for DFS (which hopefully will be better, 
>can't be much worse)
 
>As for RFCs, etc, its not like NFS, you can't get docs on much of it 
>(proprietary), you can get some old stuff for some parts of it (like the 
>non-standard RPC they use) but its hard to find.

At Stanford, we use both NFS and AFS with Kerberois (spelling?). As I user, my
original account was an NFS one originally and then I switched to AFS. Talking
about performace, I do not notice any penalty in using AFS. On the other hand,
AFS is better than NFS in backup time. As an AFS user, I found that I am 
affected less than NFS users are during server backup time. Their workstations
are just stalled while I can still work.

Yet, I do think that AFS's directory-level file protection machanism is stupid
but the per-user access privilege is a nice feature. On the down side, I once 
was really anonyed that AFS does not support file socket and I could not use
term with my Linux on my local PC.

Talk with Stanford's System Administrators. They may provide you more 
information about their experience.

Robert Pang
===============================================================================
Robert Pang           | Home:   (510)792-3678       | "Every new bug will
Computer Science Dept | Office: (415)336-5629       |  become a feature. "
Stanford University   | robpang@leland.stanford.edu | -- Donald Knuth, on his
                      |                             | claim that TeX's bug-free
===============================================================================

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Aug 1994 20:01:22 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Books&Sources TCP/UDP Programming

> "TCP/IP Illustrated, Volume 1" by W. Richard Stevens; Addison-Wessley
> 1994; ISBN 0-201-63346-9
>
> The TCP/IP Illustrated first volume discusses the
> protocols and goes slightly into applications programming. A second
> volume is due in October from Addison Wessley. This will cover more in
> the programming area than the first volume.

Actually the title is "TCP/IP Illustrated, Volume 2: The Implementation"
and it presents and covers the 4.4BSD-Lite implementation of TCP/IP.

	Rich Stevens

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Aug 1994 21:24:34 GMT
From:      doug@eng.auburn.edu (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP vs. BOOTP

In article <1994Aug18.021517.1296@ilinx.com>, brian@ilinx.com (Brian J. Murrell) writes:
> doug@eng.auburn.edu (Doug Hughes) writes:
> 
> >BOOTP = I broadcast ethernet MAC address, you give me IP address, default
> >gateway, nameserver, subnet mask, possibly microcode, maybe a cookie,
> good for when you get those mid day growlies!!---------^^^^^^^^^^^^^^
> BTW: is there a selection or only chocolate chip?? :-)
> 
any kind you want. :)

> >and other options. IP address is fixed in a table.
 
> >DHCP = like BOOTP - but IP address is dynamic. (in a nutshell)
> My question is with a net full of PC's I like to be able to do a
> "ping peter_pc" and find out if Peter's PC is alive.  How will one
> do that if the IP address changes every time they boot??  Will the
> hostname<->IP addressing be dynamic as well??
> 

DHCP is, IMHO, most useful if you have a lot of PC's who only use
addresses a little of the time (or macs).  Say you have 500 PC's
on a subnet but your subnet mask is 255.255.255.0, you can only
assign 253 subnet addresses (then subtract for any routers or hubs,
or whatever else is there). DHCP will dynamically allocate addresses
as needed. (Anybody who really does have 500 PC's on a single
subnet - with heavy net access - is probably a little bit of a masochist. :) )
 If you want fixed IP addresses, (e.g. entered in DNS) so you know who's
who (I don't blame you - gives a little added feeling of security),
and you want a well implemented product that's available now and
on just about everything, BOOTP is your answer. You'll have a centrally 
managed host table. DHCP is just starting to become available, it's not
nearly as established as BOOTP. 

-- 
____________________________________________________________________________
Doug Hughes					Engineering Network Services
System/Net Admin  				Auburn University
			doug@eng.auburn.edu
"The Light at the end of the tunnel is the headlamp of an oncoming train"

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 94 11:38:16 -0500
From:      00dfmeeker@bsuvc.bsu.edu (David Meeker)
To:        comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.multinet
Subject:   Native Prompts via TELNET

	Sorry about the crossposting, but since this question relates to 
utilizing a feature of VMS, I thought it might be somewhat appropriate. (And 
it also increases my chances of finding an answer..) 
	(And before you ask, I did look for a relevant RFC, but it's
possible that I missed it.)
	My question is this: Is there a way, using out-of-band data, (IAC 
codes?) to perform an OS level "prompt?" For instance, instead of merely 
sending a string with no CR/LF, and calling it a prompt, sending these codes
and causing the telnet client itself to issue a prompt command appropriate to
the OS? (Under VMS this would result in automatic reprompts after broadcasts
and make things much neater - no more "faking" re-prompts after output from a 
server..) It seems that this would be such an essential part of a session that
it would logically be included in the protocol...but, I've been wrong before.

Info, RFC numbers, RTFMs and Flames welcome.

--
David Meeker                                            00dfmeeker@bsuvc.bsu.edu

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 1994 04:21:57 GMT
From:      tdarcos@access1.digex.net (Paul Robinson)
To:        bit.listserv.ibmtcp-l,alt.internet.services,alt.internet.services.wanted,bit.listserv.domain-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,vmsnet.networks.tcp-ip.misc
Subject:   Looking for CNAME service

I am looking to find some site willing to add one or more CNAME records 
to their DNS tables.  I know UUNET will do this but right now I can't 
afford the $50 that they want for this.  I already have a domain name and 
I want to add CNAME records for these domain names for the time being 
until such time as I can actually provide hosts for them.  The idea is
to make them available now and then eventually set up actual sites for 
them.  

If someone is willing to add a CNAME record to their public DNS tables, 
please write me back at PAUL@TDR.COM or TDARCOS@ACCESS.DIGEX.NET.

Thank you for your assistance.


--
Reports on Security Problems: To Subscribe write PROBLEMS-REQUEST@TDR.COM
Paul Robinson - paul@tdr.com / tdarcos@MCIMail.com / tdarcos@access.digex.net
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy@psg.com>
Voted "Largest Polluter of digex.general" by Mike <voss@orange.digex.net>

-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Aug 1994 06:24:18 GMT
From:      barmar@netcom.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: detecting server status

In article <CuqrzJ.M9x@eskimo.com> kshin@eskimo.com (Kevin Shin) writes:
>I am using select() to wait for server to send input
>indefinitly.  However I would lie to detect when server 
>goes down.  I've tried setsockopt ( SO_KEEPALIVE ) but
>it did not work.
>How should it be done?

Keepalive should eventually let you know that the server has gone
down.  It doesn't kick in until the connection has been idle for a
couple of hours.  If you need something with more granularity you'll
have to implement it as part of your application protocol.

-- 
Barry Margolin                                                barmar@netcom.com


-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Aug 1994 15:39:57 -0400
From:      Chaskiel Moses Grundman <cg2v+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip,comp.sys.next.sysadmin,comp.sys.next.programmer
Subject:   BSD telnetd under NeXTSTEP?

Is anyone out there running a (recent) BSD derived telnetd under nextstep? 
(Black hardware, NS3.0 or 3.2)
I am trying to use a kerberized telnetd, but when it is used, login's
banner never appears, and characters typed do not appear to reach it.
Telnetd's banner and other information do appear, however. Telnetd's
diagnostic messages (including netdata and ptydata) are no different
from those produced by an identical telnetd running on a sun (where it
works properly).


-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Aug 1994 16:02:45 GMT
From:      geertj@ripe.net (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: Blocks of Multiple Class-C Addresses

In <33664s$nop@ccnet.ccnet.com> llmccall@ccnet.com (Lindsay McCall) writes:

>I am unclear what magic words to use on the Internic request form 
>that will get me a nice, consecutive block of about eight class-C 
>addresses.  Is there a separate form I need to use?  The form I submitted 
>got me one class-C group although I asked for more than one.  
>Incidentally, is there a way to return these addresses into the pool?  
>Maybe it's ignorance or lack of imagination, but one isolated group of 
>addresses doesn't seem much use if I really need more, and if they were 
>grouped together, it seems like I could better control my need to apply 
>routers in strategic places.  Can anybody help or direct me to a faq, RFC 
>etc that's on point?

8 C's allows for 2000 hosts. Apperently you don't have that many hosts.
If you need 8 C's because you want to set up different networks
for different purposes I suggest you use subnetting; administrative
convienence is really no reason to assign 8 C's if one will work for you.

I suggest you contact your service provider. To maximize the benefits
of CIDR and routing aggregation, your allocation should come out
of their delegation anyway.

Geert Jan



-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      21 Aug 1994 17:14:37 +0300
From:      john@gulfa.ods.gulfnet.kw (John Temples)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Looking for single-port async router


I need to connect two IP LANs over dialup, with an Internet service
provider in between, talking PPP.  I was thinking of using something
like a Cisco CS-500 asynchronous router, but this seems like overkill
for the application.  Are there any smaller (say, one or two async
port) routers that would be more cost-effective than the CS-500?
-- 
John W. Temples, III       ||       Providing the only public access Internet
Gulfnet Kuwait             ||            site in the Arabian Gulf region

-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 08:40:34 -0400
From:      gam@panix.com (Badger)
To:        comp.protocols.tcp-ip
Subject:   OS/2 TCP/IP version 2.0

I'm having trouble getting my slip account working(and getting
lamail working).  

Background:
I have successfully installed tcp/ip on 2 OS/2 2.11 workstations, that
are connected via Token Ring.  I can ping between the workstations.
I can telnet from one workstation to another.  I can send mail(using
LaMail - the package that came with the tcp/ip package) from one
workstation back to itself[the machines can talk to themselves.].
I can even set up the SLIP connection, and using the SLIP-term
application connect to my SLIP account.  It looks like its
all connected properly.  

What I can't do:
I can't send mail from one workstation to the other.

I can't do anything with the SLIP connection.  It looks like
I'm connecting but I can't telnet out, I can't FTP out, and
I can't send mail out or get newsfeeds to come in.

So, anyone have any helpfull hints on getting the mail working
or testing the SLIP connection after establishing it?

any aid is appreciated.

-Gary
gam@mhv.net/gam@panix.com
 

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 02:08:15 GMT
From:      gregw@netcom.com (Greg)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip + windows for workgroups?

I have windows for workgroups...and it works fine.  But I also have
a unix pc on that same network.  Anybody know of a program that will
give me telnet capabilities over windows for workgroups?  

Would appreciate any info.



-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 06:19:18 GMT
From:      logtel@zeus.datasrv.co.il (LOGTEL)
To:        comp.protocols.tcp-ip
Subject:   TTCP traffic generator

Hi netters,
I am looking for the public domain TTCP traffic generator.
Any help will be appreciated.

Simha Karlin, LogTel Systems Israel
e-mail: logtel@datasrv.co.il

-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 14:48:25 EST
From:      Lew@mail.med.cornell.edu (Lewis Perin)
To:        comp.protocols.tcp-ip
Subject:   Summary: Do ephemeral ports vary?

A couple of weeks ago I posted the following query:

>It's typical for a client to connect to a server without specifying a local 
>port number.  I've seen these port numbers called "ephemeral" or "anonymous". 
> There's a wide range of local port numbers a protocol stack can choose among 
>in this case.  It would seem reasonable for this port number to cycle through 
>the range rather than repeat the same one with each new [re-]connection; this 
>would probably make it easier to discard stray packets from a recently 
>dissolved connection.  Moreover, the source code of one protocol stack I've 
>read actually does this.  But that's obviously not much of a guarantee.
 
>So, if anyone knows, please:
 
>(1) Is a TCP and a UDP implementation required to make repeated requests for 
>anonymous/ephemeral local ports yield different numbers?
 
>(2) Do actual implementations do this?

I asked for email replies and promised to summarize, but only Barry Margolin 
(barmar@Think.COM) responded.  I think his message is informative and succinct 
enough to quote in full:

>In article <Lew.68.00633617@mail.med.cornell.edu> you write:
>>(1) Is a TCP and a UDP implementation required to make repeated requests for 
>>anonymous/ephemeral local ports yield different numbers?
 
>No.  In the case of TCP, the only requirement is that the tuple
><local-addr, local-port, remote-addr, remote-port> may not be used for
>2*MSL after closing a connection with such a tuple.
 
>For UDP, I don't think there's any specification about how local port
>numbers are assigned.
 
>>(2) Do actual implementations do this?
 
>I think it's most common to cycle the ephemeral port numbers in both TCP
>and UDP.

      __          perin@med.cornell.edu (212)746-2946
 |   |_  \    / : Lew Perin
 |__ |__  \/\/  : Home: (201)435-2679

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 08:28:35 +0100
From:      Simon <sb91@ecs.soton.ac.uk>
To:        comp.protocols.tcp-ip
Subject:   Q: Getting mail to SLIP/PPP machines

This may well be a very basic question (or even a FAQ, but its
not in the FAQ (if it is *please* point out to me where it is)),
but how is mail delievered from a mail server to a machine running
SLIP/PPP ? If each machine has its own IP address, it would be no
problem, but how about dynamic allocation of IP addresses. Also, how
(or what) is the IP -> hostname mapping dealt with in this case ?

Thanks

Simon
(sb91@ecs.soton.ac.uk)

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 16:49:04 -0400
From:      bforster@gandalf.ca (Bob Forster)
To:        comp.protocols.tcp-ip
Subject:   You Betcha!

Hi Kevin, how's it going? This is really cool.

-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 10:30:08 GMT
From:      brister@jolt.mpx.com.au (James Brister)
To:        comp.protocols.tcp-ip
Subject:   X through a firewall (why not?)

I've heard several times that having a firewall pass X packets through
is a security problem. Why? Is it simply that someone could embed
stolen data in the X packets and have a bogus server outside to pick
them apart, or is there more to it than that?

Thanks

James

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 11:09:03 GMT
From:      edleslie@elearn.edu.yorku.ca (Ed  Leslie)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac using Ethernet & SLIP

Bill McMullin (bmcmulli@fox.nstn.ns.ca) wrote:

: Problem:  I have to reconfigure MacTCP and reboot
: each time I want to connect to the other.

Archie around and find MacTCP Switcher. Allows you to set up MacTCP in
different ways, then save each. I put an alias of the setup of each (one for
interSLIP, the other for MacPPP) on my desktop, and clicking on the icon
switches the MacTCP setup (you must restart after, of course).

Ed

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 19:05:15 -0400
From:      bruceg@zeus.IntNet.net (Tech Force)
To:        comp.protocols.tcp-ip
Subject:   Getting IP addresses

Please tell me if I've blown it.

I sent a request for an official IP addr to hostmaster@nic.ddn.mil about 
a month ago. This was based on info in the Sun Netw Admin manual.

Is this information horribly out of date, or is the nic just really busy?



-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 94 21:40:26 PDT
From:      Blaise Barrelet <blaise@bartek.com>
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Where can I find the SLIP Specs


Hi

Does anyone know where I can find the SLIP specs.  I am trying to implement 
an SLIP dialup acces in my Windows application.

Thanks!

Blaise Barrelet
blaise@bartek.com

-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 14:43:42 GMT
From:      xtang@uoguelph.ca (Xiaodan Tang)
To:        comp.protocols.tcp-ip
Subject:   Give me an answer(socket)?


I want to transfer two files from node A to node B on LAN, which way can 
get lower cost?
	1. using one socket port on each node, transfer files one by one;
	2. using two socket ports on each node, parallel(fork) transfer
		the two files.

Dan.
Univ. of Guelph
Canada

-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 16:56:23 -0100
From:      tok@login.dknet.dk (Tom Kruhlmann)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip + windows for workgroups?

In article <gregwCuwz9r.8q5@netcom.com>, Greg wrote:
>I have windows for workgroups...and it works fine.  But I also have
>a unix pc on that same network.  Anybody know of a program that will
>give me telnet capabilities over windows for workgroups?  
>
>Would appreciate any info.
>
>
Try takeing a look at Microsofts 32 bit TCP... it looks fine
Get it via ftp at ftp.microsoft.com:/peropsys/wfw/tcpip/TCPIP32.EXE
:-)
----------------------------------------------------------------------
Tom Kruhlmann   Danish Defence Data Service
Fax +45 45660571 Phone +45 42890501,2327 Email tok@login.dknet.dk
---------------- Peace through supperior Unix Power ------------------
The facts, although interesting, are irrelevant ....

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 16:15:26 GMT
From:      caa@unify.com (Chris Anderson)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

According to Kevin Barrett <kbarrett@romulus.orl.mmc.com>:
> In article <32qicr$83c@bmerha64.bnr.ca>, hsiaoe@bnr.ca (Eric Hsiao) writes:
> > 
> > Anyway, I want to run Mosaic and be able to connect to WWW sites around the
> > world, but the problem is, there's this Internet firewall that prevents me
> > from doing so. The firewall pretty much prevents me from using any X based
> 
> Ask the system administrator of the firewall system to install Mosaic.  Then
> by passing the -display option to Mosaic, have the display sent back to your
> machine.  This is how we used to get around our firewall.  It's slow, but
> it works.

With all due respect, you have most likely compromised your firewall
using this method.  

Better: install a SOCKS interface on your firewall, and then use the 
supplied code with Xmosaic to access the internet though SOCKS.

Chris

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 16:37:37 GMT
From:      aspmdbh@cidsv08.cid.aes.doe.ca (David Howard)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Proper" use of AS #'s.

 Can someone direct me to a resource that discusses "proper" use
 of AS #'s and implications for connections to other networks ?
 
 We have at our disposal a number of registered network and AS
 numbers.  I'd like to compare our planned approaches to others'.
 
 FYI :
 
 We have a large Cisco-based tcp-ip internetwork that is moving 
 towards a "core" network for time-sensitive data exchange and
 admin traffic, and a "front-end" network on which our public-
 accessible infoservers will be placed.  The "core" network will
 carry only "internal" traffic - we do not plan for it to be
"traversed" by traffic from any of the other networks to which
 we are connected (eg:Internet, other Gov. Canada networks.)
 
 The "front-end" network will not be "traversed" by foreign traffic
 either, but it will act as a "buffer" between the core and foreign
 networks - WWW servers will sit here and feed the foreign nets.
 
 Firewalls are implemented as appropriate.
 
 
 In general, the goals are :
 
 Everyone inside can get out to the rest of the world.
 Everyone inside is able to make info available to the rest of the
 world.
 Time-sensitive data and other traffic don't interfere with each
 other.  (Or at least, not much...;-)
 
 
 Please respond by e-mail, I can summarize and re-post if there is
 a demand.
 

-- 
David Howard                     Voice  : 514-421-4777
Communication Systems Analyst    Fax    : 514-421-4703
National Network Management      E-Mail : dhoward@cid.aes.doe.ca
Canadian Meterological Centre


-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 16:39:07 GMT
From:      jkane@earth.execpc.com (Jeff Kane)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP print sharing???

berkley@kuhub.cc.ukans.edu wrote:
: Okay, here's a shot in the dark. . . .
 
: Does ANYONE know of some software (share/free/commercial, no matter) that 
: will allow you to have two PCs share a printer?  (Obviously, neither of them
: are running UNIX, but DOS.)  The program must not completely tie up either
: machine.  Also, what TCP/IP stack does it run with.  (I'd prefer LAN WorkPlace
: for DOS, but I'm slightly flexible.)
 
: Please E-mail directly.  If I find a good result, I'll post.  Thanks!

This is an ongoing question.  There are a few for just windows that use 
winsock.  But only one that I have found for plain DOS or even DOs inside 
of windows.  The one that works stand alone is Wollongong Pathway.  I in 
no way endorse this product.  I mearly state that they have a LPR 
redirector for DOS.  The rest of the product is up to you to decide. I 
personally use LWP.  I have not found a LPR redirector for it yet. That 
is on a peer to peer basis.  If you have a UNIX NFS server somewhere, you 
cahn use NFS to redirect printiong with the LWP NFS client included with 
4.2 LWP.  But the lack of such a box means your choices are limited.  
Either way, you will need a printserver for the printer that supports 
LPR.  I have use two of them successfully. One is From Pacific Data and 
is a Card for a HP laser jet 4.  The other is from Milan and it is an 
external box.  If you require an internal board the PacData is fine, For 
more flexability the Mialn is a good peer to peer LPR printer.  It also 
supports remote care and maintence via Telnet!  

Finally, the product Deskview/X is a LPR server and will do all of this 
for uou, if you can live with it's problems.  Slow and not very good at 
managing memory.  This is contrary to what Quarterdeck will tell you.  
They assume you are just loading one or two TSR's though.  It does work 
as a Dos sulution but creates a new type windowing environment that is 
why you are not using windows 3.1.  So it is a trade off.  But, if your 
apps are DOS, DVX is a better solution to LPR support than Windows and 
winsock!
-Jeff

Jeff or Diana Kane		Perfect Computer Solutions
jkane@earth.execpc.com		414-238-9075 
Network Consultants on the "Information Super Highway"

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 16:43:14 GMT
From:      jkane@earth.execpc.com (Jeff Kane)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ODI driver

Gordon L Douglass (gdouglas@world.std.com) wrote:

: 	I am looking for an ODI driver that displays TCP packets over
: 	a LAN. I believe the name is on the lines of ephload???
: 	Does / Can anyone direct me to the location of this driver??

ETHERLOAD  ....   I have it but do not remember where I got it at.  It is 
very limited.  It has a limited display packet size and some other little 
irritants.  I went out and got lanalyzer for windows.  It is very good 
and has great filters!  It is in the $1,000 range, but is worth it!

--
Jeff or Diana Kane		Perfect Computer Solutions
jkane@earth.execpc.com		414-238-9075 
Network Consultants on the "Information Super Highway"

-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 17:34:03 GMT
From:      shark@netcom.com (Stefan Sharkansky)
To:        comp.protocols.tcp-ip
Subject:   Re: Books&Sources TCP/UDP Programming

>conrad@hathi.informatik.rwth-aachen.de (Christoph Conrad) writes:
>
>>are there any good books about TCP/UDP--programming?
>>I am looking also for sources in this topic and hints how to
>>implement intelligent client/server concepts with TCP/UDP,
>>especially recovery strategies (client crashes, server hangs etc.).

I teach a course called "UNIX Network Programming" for the Extensions of
the University of California - Berkeley and UC Santa Cruz, and use the
following books in the class:

"TCP/IP Illustrated, Volume 1" by W. Richard Stevens; Addison-Wessley
1994; ISBN 0-201-63346-9

"Internetworking with TCP/IP" Volume III, Client - Server programming and
Applications (BSD Socket Version) by Douglas E. Comer and David L. Stevens;
Prentice Hall 1993; ISBN 0-13-474222-2

(ISBN Numbers from Al Longyear)

If you want a higher level discussion of distributed systems, look at
"Distributed Systems" by Sape Mullender, second edition.  I don't recall the
publisher. 


Stefan

--

Stefan Sharkansky
Prospero Systems Research, Inc.
USMAIL	520 Frederick St. Box 19, San Francisco, CA 94117
VOICE	(415) 731-8114		FAX  (415) 731-3395
E-MAIL	shark@netcom.COM

-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 94 18:11:41 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: 1 host, 2 cards, same address?

In article <330d24$98o@hacgate2.hac.com> rbrandt@hac.com (Richard Brandt) writes:
>This isn't in the FAQ and although I've seen it addressed here I don't think
>I've gotten the answer I need.  For various applications I've run across, for
>redundancy or for load sharing, it seems to be a good idea to have a host that
>has 2 interfaces onto the same ethernet or FDDI segment.  That would imply
>that the network portion of the IP address for both interfaces would be the
>same while the host portion could be different.  Now it seems that I've heard
>that at least an older version of SunOS wouldn't let you do that.  I've heard
>different stories from different persons on whether that is still true for Sun
>and all the other vendors (IBM, HP, DEC, SGI).  What I would like is to hear
>from the net is if someone has done this and what if any problems they've had.
>If it can be done (and it may be an OS by OS case) how is 1 interface chosen
>over another?  The source code for IP seems to take the target IP address and
>strip the network portion and then do a table match on the interface cards.
>That would imply the same interface is chosen first all the time.
>
>The other question, if this can be done, is what happens if you get an IP 
>broadcast?  Wouldn't 2 copies of the same packet go up the stack? 
>

Except for the redundancy case, I would recommend against installing a
second controller on the same physical network.  Most machines (not
all) can drive a single ethernet interface at network speed (I know
the Sun Sparc's and Data General AViiON's can).  If your machine can
transmit and receive at network speed, you cannot improve throughput
without a waiver exempting your network from the 180,000 mile per
second speed limit.  In most cases network throughput will go down
due to increase system overhead (increased number of interrupts,
increased memory bus contention, etc.).

SunOS sets a system MAC address on all interfaces.  DGUX uses the
interface factory interface (though you can override the MAC address).
I don't know about the other vendors you have named.

How the interface is chosen depends on the networking code.  The most
modern BSD code (if one can call BSD modern) will not allow you to
have more that one route per destination.  Previous versions allowed
one to have multiple routes and chose the route to use based on
use count (this is what DGUX does).

IF this is done, you will receive IP broadcasts twice; once for each
interface.


The information and opinions I have provided you is based on ethernet
controllers.  I do not have complete data to comment on FDDI controllers.

Disclaimer: Most information about computer hardware and software is
obsolete before it's written.  This is information no different.
--
John A. Scott                         Data General
Phone: +1 919 248 5995                62 TW Alexander Drive
Email: scott@rtp.dg.com               Research Triangle Park, NC 27709

-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 18:16:12 GMT
From:      longyear@netcom.com (Al Longyear)
To:        comp.protocols.tcp-ip
Subject:   Re: OS/2 TCP/IP version 2.0

gam@panix.com (Badger) writes:

>What I can't do:
>I can't send mail from one workstation to the other.
 
>I can't do anything with the SLIP connection.  It looks like
>I'm connecting but I can't telnet out, I can't FTP out, and
>I can't send mail out or get newsfeeds to come in.

This is not really a problem for this news group. It belongs over
in the os2 news groups. However, I'll take a crack at it.

GET CSD 50383 (at least this level.)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What you described is exactly what the CSD fixes.

The CSD is on software.watsun.ibm.com.
-- 
Al Longyear           longyear@netcom.com

-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 16:49:07 +0100
From:      robjan@rabo.nl (Rob Janssen)
To:        comp.protocols.tcp-ip
Subject:   Re: Any vendors of TCP (without IP)?

In <32vpsu$6s6@aisun.aiinet.com> tom@aisun.aiinet.com (Tom Herbert) writes:

>My point is that once you take away the IP encapsulation from TCP, odds are
>you are immediately making yourself inoperable with most vendors who have
>implemented 793 (with IP in mind).  If you'll NEVER have to communicate with
>another vendor, or you'll NEVER need to route across IP networks, then I
>say go for it.

Of course when you don't use IP to transport the TCP segments, you will
not be able to communicate with others anyway.  When you want to do so
at some time, you will need a gateway that moves TCP segments between the
IP encapsulation and your own private encapsulation.  That gateway can
translate the checksum at the same time.
(remember that TCP checksum changes can be done incrementally, so you can
do the translation from your own pseudo-header to the IP pseudo-header
specified in RFC793 without re-computing the checksum over the entire
segment)

Rob

-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 18:51:57 GMT
From:      kerch@reynaldo.PARC.Xerox.Com (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksum

>>>>> "Gary" == Gary Wright <gwright@connix.com> writes:
    >> See RFC's 1071 and 1141.
    Gary> Note, RFC 1141 has been updated by RFC 1624.

Yes, but that doesn't change the TCP checksum algorithm.
--

Berry Kercheval :: kerch@parc.xerox.com 
"WARNING: Objects in calendar are closer than they appear!"



-----------[000513][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 18:56:52 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.dcom.cell-relay,comp.benchmarks,comp.protocols.tcp-ip
Subject:   Netperf-1.9alphaPL4

Folks -

Netperf-1.9alphaPL4 is now ready and waiting on ftp.cup.hp.com under
dist/networking/benchmarks/exp 

This version has FORE_STREAM and FORE_RR tests which should work on
both Solaris 2.3 and HP-UX 9.X. (Those have been "tested"). Those
familiar with netperf will find that the FORE_* tests are quite
similar to the UDP_* tests, since there can be packet loss.

Caveats:

I still no not know how I should be reporting what the QoS and such
become. For the time being, the packet burst size is reported as the
"socket size." Informed opinions would be most welcome.

The FORE ATM API does not return ENOBUFS when it drops a packet
locally. This is different from other links on HP-UX, and IRIX (and
perhaps other systems, other than those from Sun). This can result in
netperf's reporting a send rate much higher than reality. For this
reason, people should look at the receive rate statistic *ONLY*

It would seem that that in some cases, repeated use of the FORE_STREAM
tests against a Solaris 2.3 SS20 will result in the system becoming
completely unusable. It appears to go into memory thrashing, but I'm
not certain. This probably does not appear on an HP-UX system running
the latest beta software (2.3?). The Solaris system was running 2.2
(?) and used DLPI beneath the atm_* calls whereas the HP-UX system
used sockets.

There was a race condition of some sort with the FORE_RR test under
HP-UX on HP 735's that does not appear for any of the other _RR tests
on any other links tested thusfar. It *appears* that the netserver
system does not finish with it's side of the atm_accept() processing
and get into an atm_recv() call before the netperf side can get accept
notification and send the first request. This is being kludged around
temporarily with a call to sleep(1) in the netperf code. Make sure
that you compile with -DFORE_KLUDGE.

happy benchmarking,

rick jones

-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 20:01:22 GMT
From:      mrbulli@uhost1.servtech.com (thomas bullinger)
To:        alt.internet.services,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PSI Interramp and Wollongong TCP/IP

I have a simple question:

Does anyone have any experience with PSI's Interramp dial-up service? They
say they support the Chamaleon package so I assume that other
implementations of PPP will also work.

--______ __ /\./\./\. This message contains only my own opinion ./\./\./\
    /   /  ) This address: mrbulli@cyber1.servtech.com
   /   /--<  Home address: mrbulli@btoy1.rochester.ny.us
(_/   /___/  Compu$erve  : 76535,2221

-----------[000515][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Aug 1994 20:18:52 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.pc-clone.32bit
Subject:   Re: SLIP verses PPP

In article <1994Aug15.122022.21200@pcthree.com> scum@pcthree.com (Steve Monroe) writes:
   larry@gator.rn.com (Larry D Snyder) writes:
      I'm running SLIP that came with Dell 2.2...
   
   That's if you can find [PPP] to run on your Dell 2.2.  PPP on
   PC/Unix seems to be largely ignored by commercial and free markets.
   
This isn't an advertisement, but please don't get the impression that
commercial PPP vendors are all ignoring that market.

We do lots of business with people using PCs running any of several
flavors of UNIX, including Solaris/x86, Unixware, Interactive UNIX,
SCO Xenix, BSDI BSD/386, NeXTStep/Intel, and SCO UNIX.  And as others
have already pointed out, several PPP implementations are freely
available for UNIX systems running on PCs.

Since there have been relatively few requests for our software on
Dell's UNIX, we haven't invested the work to do that port.  Contact
our Marketing group (Marketing@MorningStar.Com) if you'd like to
persuade them to change their view of the possibilities in a
particular market niche, or with a particular port.
--
Bob Sutterfield, Tech Support Manager
Morning Star Technologies                                       +1 614 451 1883
3518 Riverside Dr, Suite 101, Columbus Ohio USA, 43221-1754     +1 800 558 7827
support@MorningStar.Com                                    Fax: +1 614 459 5054

-----------[000516][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 20:50:52 GMT
From:      mrbulli@cyber1 (thomas bullinger)
To:        alt.internet.services,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PSI Interramp and Wollongong TCP/IP

The first post had an incorrect reply address.

thomas bullinger (mrbulli@uhost1.servtech.com) wrote:
: I have a simple question:
 
: Does anyone have any experience with PSI's Interramp dial-up service? They
: say they support the Chamaleon package so I assume that other
: implementations of PPP will also work.

--______ __ /\./\./\. This message contains only my own opinion ./\./\./\
    /   /  ) This address: mrbulli@cyber1.servtech.com
   /   /--<  Home address: mrbulli@btoy1.rochester.ny.us
(_/   /___/  Compu$erve  : 76535,2221

-----------[000517][next][prev][last][first]----------------------------------------------------
Date:      22 Aug 1994 23:01:30 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Weird TCP/IP problem


In article <33b7rn$5gf@schema.fiu.edu>, cris@fiu.edu (Cris Moore) writes:
|
|We've have been having a problem with connections to hosts on our 
|network from hosts outside our network. 
|
|I've been trying for about a month to isolate and correct the problem but 
|not with much success.
|
|The problem:
|    Sessions (Telnet or FTP) from outside hosts (I've tried from several)
|to our hosts will freeze. I have example files (enclosed in uuencoded
|format below) that if I attempt to "FTP get" or "cat" them from outside
|hosts will always freeze the session.  Some of the "motd/login" banners
|also lock up outside sessions and even some "ls" directory listing or 
|"vi" sessions. 
 
| [...]
 
|I'm at my wits end trying to discover the cause of this problem.
|
|If you can point me to other troubleshooting that I could perform, I 
|would be most grateful.

Yeah, this sounds like a wicked difficult problem very similar
to one I'm trying to track down on my campus.

The problem is almost certainly *not* a TCP/IP problem, but a 
lower-layer problem affecting a repeater or transceiver or 
CSU/DSU or some such gizmo.  It could be, for example, a fiber
run that's just a shade too long.  The manifestation is that packets
containing certain data packets don't get thru.  

How to troubleshoot it is: drop in a packet analyzer at each point
in the network path between point A and B while the sender is
attempting to transmit the "bad" pattern.  Find out which box/line
is failing to transmit it, and fix it.

Easier said than done!

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000518][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 00:04:59 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Weird TCP/IP problem


In article <33baoa$r10@news.CCIT.Arizona.EDU>, I wrote:

||We've have been having a problem with connections to hosts on our 
||network from hosts outside our network. 
||
||I've been trying for about a month to isolate and correct the problem but 
||not with much success.
||
||The problem:
||    Sessions (Telnet or FTP) from outside hosts (I've tried from several)
||to our hosts will freeze. I have example files (enclosed in uuencoded
||format below) that if I attempt to "FTP get" or "cat" them from outside
||hosts will always freeze the session.  Some of the "motd/login" banners
||also lock up outside sessions and even some "ls" directory listing or 
||"vi" sessions. 
 
|| [...]
 
||I'm at my wits end trying to discover the cause of this problem.
||
||If you can point me to other troubleshooting that I could perform, I 
||would be most grateful.
|
|Yeah, this sounds like a wicked difficult problem very similar
|to one I'm trying to track down on my campus.
|
|The problem is almost certainly *not* a TCP/IP problem, but a 
|lower-layer problem affecting a repeater or transceiver or 
|CSU/DSU or some such gizmo.  It could be, for example, a fiber
|run that's just a shade too long.  The manifestation is that packets
|containing certain data packets don't get thru.  
|
|How to troubleshoot it is: drop in a packet analyzer at each point
|in the network path between point A and B while the sender is
|attempting to transmit the "bad" pattern.  Find out which box/line
|is failing to transmit it, and fix it.
|
|Easier said than done!

Since I posted this, I figured out an easier way to pinpoint
a data dependent error.

First, I took the file that wasn't passing and chopped it down
till I found the smallest failing piece.  Which turned out to
have a long string of lit bits (i.e. hex FFFFFFFF FFFFFFFF).

Then I tried using a PING client (cisco's) that allows you to 
specify the bit pattern, and triangulated the problem by PINGing
to various locations, and seeing which ones didn't get the all
one's packets.  This seems to indict one particular repeater.

Hope this helps,

Aaron

-----------[000519][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 01:38:31 GMT
From:      eezy@gulf.net (eezy)
To:        comp.protocols.tcp-ip
Subject:   Re: help needed for mosaic

In article <32ok8c$nm5@News.Simplex.NL>, pop0002@xs1.simplex.nl (R. Seosahai) says:
>I downloaded win32s version 1.15a. I installed it succesfully. There were 
>no problems with intsalling it. There is a program that comes with win32s.zip
>(A card game). When I start the card game, It starts up, but then when I
>click on a menu, the menu highlights but the rest of the menu does not
>show. Then my windows becomes unstable so I have to close the application.
>
>I have the same problems with mosaic for win32.

Viper:  Sorry to say ... It's RAM.  Get some.   eezy

-----------[000520][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Aug 1994 03:36:50 GMT
From:      longyear@netcom.com (Al Longyear)
To:        comp.protocols.tcp-ip
Subject:   Re: Q: Getting mail to SLIP/PPP machines

Simon <sb91@ecs.soton.ac.uk> writes:

>This may well be a very basic question (or even a FAQ, but its
>not in the FAQ (if it is *please* point out to me where it is)),
>but how is mail delievered from a mail server to a machine running
>SLIP/PPP ? If each machine has its own IP address, it would be no
>problem, but how about dynamic allocation of IP addresses. Also, how
>(or what) is the IP -> hostname mapping dealt with in this case ?

The simpliest approach is to use a store and forward mail system, such as
POP. Obviously, the central mail system would not have a dynamic IP address.
However that is only one machine on the network.

There is no problem for a dynamic IP address to generate outbound mail.

-- 
Al Longyear           longyear@netcom.com

-----------[000521][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 04:18:56 GMT
From:      lvandyke@balboa.eng.uci.edu (Lee Van Dyke)
To:        comp.protocols.tcp-ip
Subject:   Info wanted: Can two differently manufactured hubs work together?


Hi, my boss asked me today: "Info wanted: Can two differently
manufactured hubs work together without any modifications?"

I said : "I'll ask the net". Anyone know the answer?

TIA,

--
Lee Van Dyke
      	lvandyke@balboa.ece.uci.edu,
      	lvandyke@cmesa.infotec.com
	714-241-8254

-----------[000522][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Aug 94 09:28:19 CDT
From:      ljallen@VNET.IBM.COM
To:        comp.protocols.tcp-ip
Subject:   (Q) What is QUIESCE?

Has anyone experience with the 'quiesce' function of TCP/IP?
What is it and how is it used?
Thanks.

-----------[000523][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 01:38:14 +0200
From:      agulbra@tigern.nvg.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting IP addresses

In article <33bavb$gmu@zeus.intnet.net>,
Tech Force <bruceg@zeus.IntNet.net> wrote:
>I sent a request for an official IP addr to hostmaster@nic.ddn.mil about 
>a month ago. This was based on info in the Sun Netw Admin manual.
>
>Is this information horribly out of date, or is the nic just really busy?

Horribly.  Internic.net and CIDR has both changed that procedure.

Talk to your IP provider (the company which connects you to the net)
to get more IP numbers.

--Arnt


-----------[000524][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 16:48:38 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: X through a firewall (why not?)

In article <barmarCuz23s.Dxw@netcom.com> barmar@netcom.com (Barry Margolin) writes:
>If someone can access your X server from outside, they can get the
>contents of your screen, capture your keystrokes, tell it to send
>events to its clients (i.e. generate fake input -- such as commands
>in an xterm window), etc.

  If they can figure out the IP address of your X.terminal and know
  a bit of x stuff they can even play little tunes on the built-in
  speaker of most xterms.   Not that I would EVER do that, not me, no
  sir, never. 



-----------[000525][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 21:20:14 -0700
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   Re: How do I subnet a Class B Address?

herbr@netcom.com (Herb Rosenberg) writes:

>Subject: How do I subnet a Class B Address?
>Newsgroups: comp.dcom.lans.ethernet
>Organization: NETCOM On-line Communication Services (408 261-4700 guest)
>Summary: 
>Keywords: 
 
>I just received a Class B internet address and I am wondering where to 
>get an RFC or other information on how to properly to the TCP/IP  sub 
>netting.
 
>I have 60 Novell File servers,running ipx and tcp/ip, each with 5-6 local
>segments, connect to Wellfleet routers across a WAN. I also have several
>unix hosts.  If the Class B address gives me 255 networks, I already have
>300-360 network segments, I know I have more than enough addresses, but
>need clarification on how to properly to the subnetting. 
 
>Any comments would be appreiated.
>Thanks.

A subnet mask of 255.255.255.0 will give you the 256 nets of 256 hosts
on each net (well, not entirely true, you actually get a tad less).
You could subnet it to 255.255.254.0, which should give ya 512 nets of
128 hosts each.  If you want to get very clever, take a look at OSPF
(Open Shortest Path First), which Wellfleet provides a good implementation
of and will give you variable sub-netting (ie, a different subnet mask
for each LAN).  A couple of RFC's cover all of this (I don't remember the
numbers off hand).  I would recommend picking up a good book on
TCPIP.
-- 
    /|                          Tom Brink
 \`o.0'                         tbrink@crl.com
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000526][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 14:11:55 GMT
From:      neepc@solomon.technet.sg (NEE Pai Chee)
To:        comp.protocols.tcp-ip
Subject:   How to get pass fire well?

My friend has a machine that is behind a fire well.  He can only access
the machine in the campus.  When he is out of campus, he cannot telnet
or ftp into his own machine.  However, he found out that port 25 (SMTP)
is accessable from outside.

I suggest a solution to him: patch the SMTP program that he has to
accept additional commands, e.g. TELNET.  What he can do is
	telnet hostname 25
When the SMTP program answer, issue a 'TELNET' command.  Then the
SMTP program will call up the real TELNETD and transfer the control
to it.  In this way, TELNET and SMTP can share the same TCP port.
And it can beat the Fire well.

My question is: is the any such SMTP program available?  I do not
want to re-invent the wheel. (The machine is Sun sparc LX).

Thank you.

Nee Pai Chee

  

-----------[000527][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 14:35:21 GMT
From:      christb@infmuc (Christian Barmala)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.apps,comp.os.ms-windows.apps.misc,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.win32,comp.os.ms-windows.programmer.networks,comp.os.ms-windows.networking.misc
Subject:   Re: Canned API for SLIP/PPP dialup scripting, Modem Config., etc?

For Problem "1)" you may have a look to the "modem.inf" file,
that comes with Windows for Workgroups and Windows NT. The
Windows NT manual describes this file.

Christian Barmala


-----------[000528][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 16:36:35 GMT
From:      dank@alumni.caltech.edu (Daniel R. Kegel)
To:        comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip
Subject:   Re: TCP/IP Advantages?

clee@interlog.com (Chris Lee) writes:
>I'm trying to figure out the advantages of TCP/IP.  Can someone give me some 
>insight, and or point me in a direction to find it.

1. Its definition is free.  Anyone can get all the info needed to implement
   it without paying licensing fees.
2. It is simple (in contrast to the OSI protocols).
3. It was widely seeded into the community because it has often been bundled
   with popular operating systems.  In particular, Unix, starting with
   (I think) BSD 4, and now MS-Windows for Workgroups.
4. From the beginning, it was meant to work well over long distances,
   so it incorporated 'windowing' to keep throughput high even in the face
   of transmission delays.  IPX, in constrast, has had horrible throughput
   problems on slow lines, as it was designed for small Ethernets with no
   delay.  (I think they've tried to address this in recent releases.)
5. It has a simple, popular API: Berkeley sockets.  (IPX, in contrast,
   had a confusing, messy API in the past; Novell now has a good api
   for IPX.)
6. It has a huge community of people developing for it and using it.
- Dan Kegel


-----------[000529][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 06:22:56 -0500
From:      grefen@convex.com (Stefan Grefen)
To:        comp.protocols.tcp-ip
Subject:   Re: XTP availability?

In article <Cv0FrE.7pI@nist.gov>, Jim West <west@osi.ncsl.nist.gov> wrote:
>In article <33dgkt$14pc@bigblue.oit.unc.edu> gogan@hermes.oit.unc.edu (Jim Gogan) writes:
>>
>>Question: what ever happened to XTP (for faster file transfers than FTP can provide)?
>
>Not really.  XTP was a proposed replacement for transport layer protocols
>(ftp is an application layer protocol).  As far as I know XTP never progressed
>beyond proto-types.  XTP = eXpress Transport Protocl.
>
>>We're looking for as quick a way as possible to move many/large tar'd files from one
>>system to another over an FDDI net.  Assuming XTP still lives, is that the best way
>
>Assuming you have a good TCP/IP implementation, you should be able to transfer
>these files as fast as your hosts can (you'll probably find that the
>bottleneck is in the host with how fast it can copy data between memory
>locations).

Well there is one (minor) problem. If your tcp_recvspace is small your
tcp-window will be small too. Normal workstations have between 4k an 7k
recvspace. On FDDI this degrades TCP to a ping-pong protocol (req-ack-req ..).
On most machines you can patch that value by changing the the
tcp_send_space and tcp_recvspace kernel variables. The provide the default
value if it is not changed by the application (on BSD systems setsockopt(2)).

Setting this to values like 63k gives a good speedup over FDDI. If your
TCP-implementation support window-scaling I think you can increase it up to
1 Meg. (I would like to have an option to set the default to n times tcp_mss
to limit the number of outstanding packets instead of bytes ...)

Increasing tcp_sendspace might reduce the number of context switches on the
sender, increasing tcp_recvspace on the receiver side  will change the
tcp-windowsize for this connection.

Hacker guide to patch the running kernel:
on a Convex: adb -k -w /vmunix /dev/mem 
	     tcp_sendspace/=w <hexvalue>
	     tcp_recvspace/=w <hexvalue>
	     ^D
	     

on a HP: adb -k -w /hp-ux /dev/mem 
	     tcp_sendspace/W <hexvalue>
	     tcp_recvspace/W <hexvalue>
	     ^D

on most systems : adb -k -w /<kernel> /dev/mem 
	    tcp_sendspace/<see manual> <hexvalue>
	    tcp_recvspace/<see manual> <hexvalue>
	    ^D

Hacker guide to patch the kernel-binary:
on a Convex:  on the spu add tcp_*space to /mnt/os/tunables and add 
tune cpu tcp_sendspace <value>
tune cpu tcp_recvspace <value>

on a HP: adb -k -w /hp-ux 
	     tcp_sendspace?W <hexvalue>
	     tcp_recvspace?W <hexvalue>
	     ^D

on most systems : adb -k -w /<kernel> 
	    tcp_sendspace?<see manual> <hexvalue>
	    tcp_recvspace?<see manual> <hexvalue>
	    ^D

In ConvexOS 11.0 there is a site command for the ftpd and a new command in
ftp to change the window sizes. But it shouldn't  be too hard to add this
to the standard *BSD ftp/ftpd.

>>to go?  If so, anyone know about binary availability for AIX (RS6000) and ConvexOS?

There is no XTP for ConvexOS but see above how to speed up TCP.
BTW. The default for tcp_*space is 31k on a Convex.

>
>Jim West

Stefan Grefen


-- 
Stefan Grefen                          Convex Computer GmbH, Frankfurt, Germany
grefen@convex.com		       Phone: +49-69-665270


-----------[000530][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Aug 1994 22:57:14 GMT
From:      west@osi.ncsl.nist.gov (Jim West)
To:        comp.protocols.tcp-ip
Subject:   Re: XTP availability?

In article <33dgkt$14pc@bigblue.oit.unc.edu> gogan@hermes.oit.unc.edu (Jim Gogan) writes:
>
>Question: what ever happened to XTP (for faster file transfers than FTP can provide)?

Not really.  XTP was a proposed replacement for transport layer protocols
(ftp is an application layer protocol).  As far as I know XTP never progressed
beyond proto-types.  XTP = eXpress Transport Protocl.

>We're looking for as quick a way as possible to move many/large tar'd files from one
>system to another over an FDDI net.  Assuming XTP still lives, is that the best way

Assuming you have a good TCP/IP implementation, you should be able to transfer
these files as fast as your hosts can (you'll probably find that the
bottleneck is in the host with how fast it can copy data between memory
locations).
>to go?  If so, anyone know about binary availability for AIX (RS6000) and ConvexOS?

Jim West

-----------[000531][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 07:51:15 -0500
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip
Subject:   Re: Blocks of Multiple Class-C Addresses

In article <33ddgs$noc@ccnet.ccnet.com>,
Lindsay McCall <llmccall@ccnet.com> wrote:
>Geert Jan de Groot (geertj@ripe.net) wrote:
>: In <33664s$nop@ccnet.ccnet.com> llmccall@ccnet.com (Lindsay McCall) writes:
 
>: >I am unclear what magic words to use on the Internic request form 
>: >that will get me a nice, consecutive block of about eight class-C 
>: >addresses.  Is there a separate form I need to use?  The form I submitted 
>: >got me one class-C group although I asked for more than one.
>  
>[Here, I omit the rest of my earlier message]
>
>: 8 C's allows for 2000 hosts. Apperently you don't have that many hosts.
>: If you need 8 C's because you want to set up different networks
>: for different purposes I suggest you use subnetting; administrative
>: convienence is really no reason to assign 8 C's if one will work for you.
>
>Geert Jan, thank you for your comments.
>
>I will initially have about 1500 people with workstations 
>plus SNMP network equipment.  I would love to assume DHCP will be 
>workable by the time I run out of addresses, and I would love to assume 
>that I will be able to keep most of these workstations from needing 
>direct Internet connections, but everything I'ver heard so far is that 
>you should avoid making up your own IP addresses, and each of those 
>workstations will need an IP address for internal networking.  I suppose 
>I could deal with this piecemeal, but I'm hoping I can plan a good deal 
>of this out beforehand.
>

For some reason I never heard, when we started running IP, we were using
97. as if we owned it; since we didn't, we had to change to something we
_did_ own. For the record, you will be astounded at the number of places
you have to change IP addresses if you renumber your net, and amazed at the
number of problems you encounter trying to do this change while providing
something like service. (Our biggest problem, which showed up when we were
flipping back and forth between network numbers, was mainframe LAN interfaces
that didn't flush arp caches, but there were PLENTY of problems. We're a lot
smarter now, but it took about 8-10 people about 14 hours to renumber about
300-400 workstations, PCs, MACs, and mainframes, and for us, the coordination
was the killer.) If you have the chance to get real IP addresses, don't waste
it -- get the right ones!

>: I suggest you contact your service provider. To maximize the benefits
>: of CIDR and routing aggregation, your allocation should come out
>: of their delegation anyway.
>
>Hmmm, good point.  Still, connecting to the net is phase 2 of this 
>project.  We will still need addresses to use internally, and it 
>would be nice if I didn't have to go back and change them later.

A lot more than nice! You'll be looking for portable PCs that were off
the net during the change for _days_, and, of course, their old host
address (minus the subnet mask) will be a duplicate of your most vital
servers' addresses (ask me how I know...)

Good luck!
-- 
-  Spencer Dawkins	Internet: dawkins@bnr.ca   (214) 684-4827           -
-  "Everything I need to know, I learned reading .signatures on the net"    -

-----------[000532][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Aug 1994 23:44:34 GMT
From:      herbr@netcom.com (Herb Rosenberg)
To:        comp.protocols.tcp-ip
Subject:   How do I subnet a Class B Address?

Subject: How do I subnet a Class B Address?
Newsgroups: comp.dcom.lans.ethernet
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Summary: 
Keywords: 

I just received a Class B internet address and I am wondering where to 
get an RFC or other information on how to properly to the TCP/IP  sub 
netting.

I have 60 Novell File servers,running ipx and tcp/ip, each with 5-6 local
segments, connect to Wellfleet routers across a WAN. I also have several
unix hosts.  If the Class B address gives me 255 networks, I already have
300-360 network segments, I know I have more than enough addresses, but
need clarification on how to properly to the subnetting. 

Any comments would be appreiated.
Thanks.


-- 
herbr@netcom.com

-----------[000533][next][prev][last][first]----------------------------------------------------
Date:      23 Aug 1994 23:53:07 GMT
From:      michael@seawest.seachange.com (Michael Burke)
To:        comp.infosystems.www,comp.protocols.tcp-ip,comp.security.unix,alt.internet.services
Subject:   Re: Bypassing internet firewall

In article <GFE.94Aug23155024@vritra.cb.att.com>, gfe@vritra.cb.att.com (Gary Ellison) says:
>
>>>>>> "-" == Brad R Wetmore <wetmore@bongos.EBay.Sun.COM.> writes:
 
>Bingo. What has to be done is to modify the browser source to be
>proxitized, ie; it knows how to get over your firewall.
>
>However, there is an alternative to modifying the browser. Most
>browser incantations support the notion of an http_proxy machine. So
>instead of modifying the browser you modify the CERN httpd (don't
>think NCSA's httpd supports proxy requests) to be proxytized and then
>point your browser to it. The browser will issue GETs to the
>http_proxy machine for every url and the http_proxy will either fetch
>the url internally or externally.

Or an even better approach is to get a firewall that can use standard
client software within the trusted network.

Sea Change Corporation provides such a beast. It is the Janus, Firewall
Server. I don't want to get too sales oriented here, if you'd like more
information send e-mail to infor@seawest.seachange.com on the west coast
or info@seachange.com from elsewhere.

Michael Burke
Sea Change Corporation
michael@seawest.seachange.com

"http://www.seawest.seachange.com"

-----------[000534][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 12:57:07 -0700
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   Re: How do I subnet a Class B Address?

berke@panix.com (Wayne Berke) writes:

>tbrink@crl.com (Tom Brink) writes:
 
>>A subnet mask of 255.255.255.0 will give you the 256 nets of 256 hosts
>>on each net (well, not entirely true, you actually get a tad less).
>>You could subnet it to 255.255.254.0, which should give ya 512 nets of
>>128 hosts each.  If you want to get very clever, take a look at OSPF
 
>I think you mean 128 subnets of 512 hosts each.
 
>255.255.255.128 gives you 512 subnets of 128.

Nuts!!  Right you are.  It was late when I was counting bits....

>--
>Wayne Berke
>berke@panix.com
-- 
    /|                          Tom Brink
 \`o.0'                         tbrink@crl.com
 =(___)=                        Paradise Valley, Arizona
    U ACK!THPTPTPT!

-----------[000535][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 08:56:23 -0400
From:      t9139ic@cfc.com (Irwin Castelino)
To:        comp.databases.sybase,comp.lang.c,comp.protocols.tcp-ip
Subject:   TCP/IP and Sybase problem


The following problem seems to be causing us a lot of grief:

We are running Sybase on SUN workstations w/t client apps accessing the Sybase
server through powerbuilder screens and code.

The tcp_keepalive parameter on the UNIX station is set for 300000 which is
5 minutes.

Now the situation is that, when a client accessing the Sybase database dies
or goes away, the sybase server still keeps these connections after the 5 
minutes time interval. In fact when one looks at them in sybase through
isql, it show the processes in a SLEEP(generally RECV SLEEP) state.
Pretty soon the Sybase server runs out of connections, and one has to go in
and increase the limit to accomodate these sleeping processes. Is this a
known problem? IS there a fix for it?

Does Sybase set the SO_KEEPALIVE parameter on their internal socket connections?

CAN SOMEONE PLEASE HELP....................

Thanx in advance.

irwin@cfc.com


-----------[000536][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 1994 03:59:03 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip
Subject:   Re: broadcast on multiple interfaces.

Wen-Hui Luo <wenhui@news.cs.columbia.edu> wrote:
>I have a situation which requires a machine with 2 interfaces able to
>send and receive boardcast packets using 255.255.255.255 and
>meanwhile, able to tell which interface where the packet comes from.
>Natually, I created two sockets, one for each interface and 
>with its own IP address binded to each socket.  However, what happens
>is that no boardcasted packet is able to come in from the interface
>throuth the socket. Depending on which tcpip kernel you are using,
>sometimes it doesn't boardcast using the socket binded to a specific
>IP address and using 255.255.255.255 as the out going IP address.

I'm fairly sure you can do what you want with 1 socket.
If you bind to INADDR_ANY, you should receive broadcast packets from
both interfaces. To send broadcast packets to both interfaces,
you must first find their broadcast addresses. It's a bit complicated
to explain here, but the source for rwhod has everything you need. 
Take a look at /usr/src/usr.sbin/rwhod/rwhod.c on the BSD Net2
release (I'm not sure if the path has changed in BSD4.4 and friends).
-- 
Steve Kotsopoulos  P.Eng.                         steve@ecf.toronto.edu
Systems Analyst,  Engineering Computing Facility, University of Toronto

-----------[000537][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 94 10:52:07
From:      Michel Dieu <nobody@pcsci7.sci.fundp.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Private and public IP addressing

I've got a question which may be a FAQ ... but I really don't beleive it's a
FAA (Frequently Answered Answer ;-)

Let's say I'm an Internet service provider (I'm not, but one of them asked
me the question :-O ). Now I meet a client who already have IP addressing
on it's LAN and want a connexion to Internet *without* changing it's
internal addressing scheme !

I know he'll need somewhat called a gateway ... a machine having an
Internet IP address on its SLIP (or wathever) line and a LAN IP address
on it's ethernet (or wathever).

I had to give a fast answer to my friend, and I found two solutions :

* the first was to use the gateway as a telnet server and X-win client, so
  no problem : you telnet gateway.company.be and you get all the Internet
  services ... easy but no direct access from the LAN or to the LAN
  (ftp in two stages for example).

* the second was *very* tricky :-\ It's something like what is found in
  "The design of a secure Internet Gateway" by Bill Cheswick (available
  in most security ftp archives). You have modified ftpd, telnetd, gopherd
  and so forth on the gateway, you have modified ftp, telnet, gopher clients
  on the clients. That means that you have to change [number of clients]*
  [number of architectures] proggy on the LAN !
  It works like this : I'm doing 'ftp wuarchive.wustl.edu', the modified
  client opens the connection to 'gateway.company.be' and send
  'wuarchive.wustl.edu' as a first parameter string; the modified ftpd
  on the gateway then opens a ftp connection to 'wuarchive.wustl.edu'

Any better solutions ... or pointers on where to get documentation on
building Internet gateways ...

-- 
Michel "toor:0:0" Dieu
No Email yet ... I'm waiting for a good job

-----------[000538][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 1994 05:56:03 GMT
From:      jas@talking.COM (Jim Shankland)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting IP addresses

In article <33bavb$gmu@zeus.IntNet.net> bruceg@zeus.IntNet.net (Tech Force) writes:
>Please tell me if I've blown it.
>
>I sent a request for an official IP addr to hostmaster@nic.ddn.mil about 
>a month ago. This was based on info in the Sun Netw Admin manual.
>
>Is this information horribly out of date, or is the nic just really busy?

Unless you have the misfortune to be working for the military
(just kidding, don't shoot), send your request to
hostmaster@internic.net.

Jim Shankland

-----------[000539][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 07:38:55 GMT
From:      tk@axprl1.cc.rl.ac.uk ()
To:        comp.protocols.tcp-ip
Subject:   Re: help needed for mosaic


I had a similar problem, I found that editing SYSTEM.INI under the
[DISPLAY] section change line aperture-base=100 to aperture-base=0
solved the problem.

Tim Kidd. 

-----------[000540][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 11:36:28 GMT
From:      delaroca@library.ucla.edu (Denis De La Roca)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Where can I find the SLIP Specs

Blaise Barrelet (blaise@bartek.com) wrote:

: Hi
 
: Does anyone know where I can find the SLIP specs.  I am trying to implement 
: an SLIP dialup acces in my Windows application.

Look at RFC-1055, "Non-Standard for transmission of IP datagrams over serial lines".

-- Denis

-----------[000541][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 18:59:00 -0400
From:      bforster@gandalf.ca (Bob Forster)
To:        comp.protocols.tcp-ip
Subject:   cool cats


Hiya K


EVIN, i really appreciate you teaching me this! And what a cool internet
group! What a relief to know that I'm not in with a bunch or morons - heh all you oa
you cool guys please don't biscuit me!!!! I'm new on the net and don't want any flame actio a
flame action!!
Alyssa  
Pnews


-----------[000542][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 13:37:46 GMT
From:      mak10@po.CWRU.Edu (Mary A. Kaufmann)
To:        comp.protocols.tcp-ip
Subject:   home pc tcp-ip quandry


I am sick of trying to get SLIP or PPP access.
I am trying to bring my PC @ home up as a node.
I have a leased fiber optic phone line ( no thanx to baby bells)
I have a 90 Mhz true p5 with 1.3 gig scsi drive, & and ethernet card

At CWRU they have what I would call FTP server software, that is not 
even close to what I need.

My major problem is an IP address (I have no "provider" to give me one)

Is my problem:
   (a) I really need to run a flavor of UNIX on my pc
   (b) I am just missing several picecs of software (I already have winsock
       ethernet packet drivers, mosiac.......
   (c) I am just stupid.. give it up!!!

At this point there is only one more thing to say....

"As the great Hippocrates said,'I drank WHAT?'......"

-----------[000543][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 13:55:56 GMT
From:      berke@panix.com (Wayne Berke)
To:        comp.protocols.tcp-ip
Subject:   Re: How do I subnet a Class B Address?

tbrink@crl.com (Tom Brink) writes:

>A subnet mask of 255.255.255.0 will give you the 256 nets of 256 hosts
>on each net (well, not entirely true, you actually get a tad less).
>You could subnet it to 255.255.254.0, which should give ya 512 nets of
>128 hosts each.  If you want to get very clever, take a look at OSPF

I think you mean 128 subnets of 512 hosts each.

255.255.255.128 gives you 512 subnets of 128.

>(Open Shortest Path First), which Wellfleet provides a good implementation
>of and will give you variable sub-netting (ie, a different subnet mask
>for each LAN).  A couple of RFC's cover all of this (I don't remember the
>numbers off hand).  I would recommend picking up a good book on
>TCPIP.
>-- 
>    /|                          Tom Brink
> \`o.0'                         tbrink@crl.com
> =(___)=                        Paradise Valley, Arizona
>    U ACK!THPTPTPT!
--
Wayne Berke
berke@panix.com

-----------[000544][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 14:35:45 GMT
From:      khweis@mvmpc9.ciw.uni-karlsruhe.de (Karl-Heinz Weiss)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Q: PRINTNET and W4WG

- Is there a newer version of this wonderful printserver/redirector
  then PRINTNET v1.0 ? I have the server running on a windows 3.11
  machine in a dos-box. Works great! But:
- on w4wg PC's I can print only one file over the redireted lpt.
  After the last packet is sent, the redirector tries to send
  another packet on and on without success. It looks like the
  ndisdriver refuses to send this packets.  
  If I try 'redirect off' command, the redirector claims 'printing is    
 busy'  (or similar). 
  
  I think, it's a problem of the dis_pkt.dos shim. (I have to install 
  the ndisdriver/dispkt from dos because I need the realmode           
packetdrivers for   winsock and dos applikations) 

Any idea?

Karl
--------------------------------------------------------------------
Karl-Heinz Weiss         Email: <khweis@mvmpc9.ciw.uni-karlsruhe.de>
University of Karlsruhe  Phone: (49)-721-608-2418
Germany                         (49)-7244-1792
--------------------------------------------------------------------

-----------[000545][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 15:07:10 GMT
From:      yjapts@info.vub.ac.be (Yoeri J. Apts)
To:        comp.protocols.tcp-ip
Subject:   Executables for TCPDUMP-v3.0

tcp-ip-ers,

Is there anybody who knows where I could get an EXECUTABLE version
of TCPDUMP-v3.0. I need it for a SparcStaton 10 running 
Solaris 2.3 (SunOS 5.3) using the DLPI I-face, 
but a version for SunOS 4.1.3 using Netw. I-face Tap (/dev/nit)
will do just fine. 

I spend the last days trying to compile the *tar distributions on my platform,
to no avail, guess I'm not familiar enough with all the GNU stuff.
I'm not planning on adding/changing the code, so an executable
will do just fine.

Thanks in advance.

 Yoeri Apts                         Tel: +32(0)2-6292977
 yjapts@info.vub.ac.be              Fax: +32(0)2-6292870
                                   ISDN: +32(0)2-9239936
 Dept. INFO/TW - Digital Telecommunications Group.
 Brussels Free University
 Pleinlaan 2, 1050 Brussel
 BELGIUM
 

-----------[000546][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 1994 15:15:49 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: XTP availability?

In article <33dgkt$14pc@bigblue.oit.unc.edu> gogan@hermes.oit.unc.edu (Jim Gogan) writes:
>
> Question: what ever happened to XTP (for faster file transfers
> than FTP can provide)?
> We're looking for as quick a way as possible to move many/large
> tar'd files from one
> system to another over an FDDI net. ...

One of the early goals of Protocol Engines was protocol, hardware, and
softwarethat would run full FDDI speed.  By the time PEI folded, one of
its major sources of funding and warm bodies was on the verge of shipping
a commercial UNIX product that included TCP/IP that ran over FDDI at
full speed.  By the time PEI folded, XTP was no longer a lightweight
protocol, but had become bigger and more complicated than TCP/IP (at
least IPv4).  By the end, people had figured out how to apply most of
the ideas that could have made XTP fast to TCP/IP.

Most disk file systems are still much slower than the 98Mbit/sec of
TCP/IP/FDDI.  Those that are faster are often connected with HIPPI or
Fiber Channel and use TCP/IP, UDP/IP, or proprietary protocols.

XTP made us think about speed, but didn't itself survive.


Vernon Schryver    vjs@rhyolite.com

-----------[000547][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 1994 15:54:17 GMT
From:      robert@olsen.ch (Robert Ward)
To:        comp.protocols.tcp-ip
Subject:   Bug in non-blocking connect()s ?

Does anyone have any experience putting a TCP socket into non-blocking
(FNDELAY) mode and then doing a connect() ?  I seem to have run into a
bug, which I can't find listed anywhere, whereby it *almost* always
works.  (Correct behaviour is for the connect() to return EINPROGRESS
and a later select() on that socket says there is something to read
when the connection completes).

Unfortunately sometimes the select() never says the connection is
complete even though a tcpdump shows all TCP SYN packets being
correctly sent and ACKed.  In fact the packet trace looks exactly like
that depicted on page 230 of W. Richard Stevens excellent ``TCP/IP
Illustrated Vol. I''.  Netstat also shows that the TCP connections are
established.  It's as though the client kernel occasionally forgets to
tell the user that the TCP connection is created.

The strange thing is, that if I restart the server process, all is
well once more and the non-blocking connect()s behave themselves.

If this means anything to anyone, I'd really appreciate hearing any
advice you can give.

Btw, this is SunOS 4.1.1 with various patches applied.

Thanks muchly,

	- Rob.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    J. Robert Ward,
    Olsen & Associates AG, Seefeldstrasse 233, CH-8008 Zuerich, Switzerland

Email: robert@olsen.ch        Tel.: +41 1 3864847/8        Fax: +41 1 4222282
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000548][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 1994 16:01:50 GMT
From:      robert@olsen.ch (Robert Ward)
To:        comp.protocols.tcp-ip
Subject:   Bogus EADDRINUSE returns from connect()

Has anyone seen a bug (SunOS again) whereby a connect() on a socket may
return EADDRINUSE even though no other TCP connection using the same
TCP address exists ?

I set the SO_REUSEADDR socket option, bind() this socket to a known
address and then do the connect().  This *usually* works.
Occasionally, however, if I close() this socket and repeat the same
sequence of events, the connect() only ever returns EADDRINUSE.  This
happens long after the 2MSL time-out of previous connections and after
netstat has reported disappearance of this TCP connection.  Restarting
the client process allows the bind()/connect() sequence to work once
more.

Thanks for any light shed on this,

	- Rob.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    J. Robert Ward,
    Olsen & Associates AG, Seefeldstrasse 233, CH-8008 Zuerich, Switzerland

Email: robert@olsen.ch        Tel.: +41 1 3864847/8        Fax: +41 1 4222282
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000549][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 16:55:37 GMT
From:      bmah@propaganda.CS.Berkeley.EDU (Bruce A. Mah)
To:        comp.protocols.tcp-ip
Subject:   Re: traffic generator

George Edmond Eddy writes:
> check out anonymous ftp: catarina.usc.edu:/pub/jamin you will find
> three directories: traffic, tcplib and collect.  traffic contains
> a published journal article on various types of IP traffic, ftp, 
> telnet, smtp, nntp, nv and vat.
                      ^^^^^^^^^^
This paper ("Characteristics of Wide-Area TCP/IP Conversations", by
Caceres, Danzig, Jamin, and Mitzel, from SIGCOMM '91) pre-dates nv and
vat, though it does cover the other traffic types quite nicely.

nv and vat data wasn't the original poster asked for, but for folks
interested in these (and some other) IP multicast applications, I have
a writeup of some measurements I've taken of MBONE traffic.  Send me
email if interested <bmah@cs.berkeley.edu>.

Bruce.
--
------------------------------------------------------------------------------
Bruce A. Mah		   Graduate Student	       bmah@tenet.Berkeley.EDU
		      Computer Science Division
		  University of California, Berkeley

-----------[000550][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 18:27:26 GMT
From:      impellus@cs.ucsd.edu (Tom Impelluso)
To:        comp.protocols.tcp-ip
Subject:   Quick question please


I am teaching myself about tcp/ip.

I am learning about the layers, and the
various headers put on the datastream by
each protocol.  I have a desire to "see if for
myself".

Could someone give me the command I need to
mail myself a letter and read the entire UNSTRIPPED
file as it comes in.  I would like to see the
data, and all the header files put on by the
tcp/ip suite of protcols.

Thanks,
Tom

-----------[000551][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 18:34:51 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: XTP availability?

Stefan Grefen (grefen@convex.com) wrote:
: Setting this to values like 63k gives a good speedup over FDDI. If your
: TCP-implementation support window-scaling I think you can increase it up to
: 1 Meg. (I would like to have an option to set the default to n times tcp_mss
: to limit the number of outstanding packets instead of bytes ...)

This has the added advantage of helping to insure that you can have
enough outstanding packets to trigger fast retransmit. 

There is a slight problem (?) though in that the application will not
know what the window size will be until after the connection is
established. The tcp_mss is not known until after the three-way
handshake. 

rick jones

-----------[000552][next][prev][last][first]----------------------------------------------------
Date:      24 Aug 1994 19:11:08 GMT
From:      l115136@gdwest.gd.com (Melton GL)
To:        comp.protocols.tcp-ip
Subject:   TCP fragmentation

I've noticed when dealing with TCP sockets that if the sender writes a
large amount of data in one write, the receiver may only get part of
the data in one read.  To get all of the data, the receiver has to do
additional reads.  Also, if the sender performs several small writes,
the receiver may get the data from all of those writes in a single
read.  Is there any mechanism in TCP to allow one read by the receiver
to receive the data sent in one write by the sender (as in UDP)?

I've noticed the FIN flag in the header, but isn't that only set when
the connection is ended (i.e., the socket is closed)?


Thanks,

Bud
meltongl@lfwc.lockheed.com

-----------[000553][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 1994 21:27:38 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Is MTU discovery available?

> One problem is that even though the path between nodes whould have an MTU of
> 1500 (Ethernet), the packets are always limited to 512 bytes. Tests with TTCP
> indicate that this may be a significant problem.
> 
> Does anyone know the status of MTU discovery on SGI/IRIX, DEC(OSF/1), and SUN
> (Solaris and SunOS)? If it is not implemented by vendors, is any other
> software available to do it?

I know Solaris 2.x has it, SunOS 4.1.x does not; don't know about the others.
(I just watched a TCP connection to OSF/1 V2.0 with tcpdump and it doesn't
look like they support it.)

> If not, is there any reasonable way to push the system into sending larger
> packets out to systems in other nets?

Many systems define the global "tcp_default_mss" (or something similar),
which defaults to 512.  You could bump that up to 1460.

	Rich Stevens

-----------[000554][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 1994 21:37:59 GMT
From:      hcohen@world.std.com (Howard D Cohen)
To:        comp.protocols.tcp-ip
Subject:   gateway with one controller

I am running Solaris 2.1 on a Sparc.

I would like to configure my sparc to be a gateway between two networks, but
I would like only one ethernet controller and one ethernet for both nets.

Does anyone know how to do this?

Thank you.

Howard Cohen



-----------[000555][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Aug 94 21:52:48 GMT
From:      oberman@icaen.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Is MTU discovery available?

We have recently upgraded our backbone to T3 and have been getting reports of
poor FTP throughput. Testing shows VERY poor performace on some connections.

One problem is that even though the path between nodes whould have an MTU of
1500 (Ethernet), the packets are always limited to 512 bytes. Tests with TTCP
indicate that this may be a significant problem.

Does anyone know the status of MTU discovery on SGI/IRIX, DEC(OSF/1), and SUN
(Solaris and SunOS)? If it is not implemented by vendors, is any other software
available to do it?

If not, is there any reasonable way to push the system into sending larger
packets out to systems in other nets?

R. Kevin Oberman			
Energy Sciences Network (ESnet)
National Energy Research Supercomputer Center (NERSC)
Lawrence Livermore National Laboratory (LLNL)
Internet: koberman@llnl.gov		+1 510-422-6955

-----------[000556][