The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1992)
DOCUMENT: TCP-IP Distribution List for December 1992 (344 messages, 180286 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1992/12.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 Dec 92 01:42:00 GMT
From:      gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs. Telnet

In article <1992Nov30.060319.17880@candle.uucp>, root@candle.uucp (Bruce Momjian) writes...
# 
#Having read Steven's "Unix Network Programming", what is the major
#difference between rlogin and telnet.  Here are the differences I see:
# 
#	1) rlogin is for unix-to-unix logins, telnet is for any tcp/ip
#	computer

Not just Unix.

All VMS TCP/IPs, notably MultiNet from TGV Inc., support RLOGIN as both
client and server.

#	2) rlogin assumes there is a tty terminal discipline on each
#	side of the connection, telnet does not

Close but no cigar.  Both negotiate it.

#Are there any other major differences, either in function or features?

Rlogin	- usually clients don't allow its usage with ip addresses,
	  so names must be specified
Telnet	- specify name or address

Rlogin	- by default passes a username to the remote host.  This is used
	  in automating login sequences.
Telnet	- by default passes no login parameters

Rlogin	- passes 'environment variables' such as terminal type, etc.
Telnet	- negotiates a network virtual terminal as identical as possible
	  to the source terminal.

Rlogin	- Has only two active control functions, spawn (push to background)
	  which is usally ^Z, and quit, which is ~^.  Most implementations
	  hang if they are in a read state and the remote machine is lost
	  and you try ~^.
Telnet	- Has a plethora of control functions, an escape sequence to get
	  there, and often inline help.  Also many command line options
	  (at lesat in TGV Inc.'s MultiNet TCP/IP for VMS product) allow
	  extra customization.

Rlogin	- Allows automatic authentication if a hosts.equiv or .rhosts
	  setting allows so.

#-- 
#Bruce Momjian                          |  830 Blythe Avenue
#root%candle.uucp@bts.com               |  Drexel Hill, Pennsylvania 19026 
#  +  If your life is a hard drive,     |  (215) 353-9879(w) 
#  +  Christ can be your backup.        |  (215) 853-3000(h)

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
LBJ, LBJ, how many JOKES did you tell today??!

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 92 09:47:01 GMT
From:      steve@terminus.ericsson.se (Steve Reynolds)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP/IP with NFS for PCs

Apologies for asking what I am sure is an FAQ, but this question is for a friend
so it is not a topic I would have followed before.

Can people please recommend for me CHEAP (not necessarily free) DOS implementations
of TCP/IP with NFS support. The main requirement is for a client, but server information would be appreciated also.
It is important that the system be reliable.

I will summarise EMAIL messages. 


Thanks in advance

steve


---

---------------------------------------------------
| Steve Reynolds                                  |
| Ericsson-CAMTEC                                 |
| Leicester                                       |
| UK                                              |
| TEL:    +44 533 537534                          |
| EMAIL:  steve@terminus.ericsson.se              |
 ---------------------------------------------------

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      01 Dec 92 16:22 MDT
From:      Alex V. Zaytsev <alexz@glas.apc.org>
To:        comp.protocols.tcp-ip
Subject:   rlogin works, telnet doesn't (?)


Subject: rlogin works, telnet doesn't (?)

/* Written  5:13 pm  Nov 27, 1992 by alexz in glas:tech.general */
/* ---------- "rlogin works, telnet doesn't (?)" ---------- */
Friends,

obviously, something goes wrong with our TCP/IP link
between two local machines glas and glas2 connected each other
over Ethernet.

telnet glas from shell on glas2 and vice versa, telnet glas
from shell on glas result in the same error message:

"Connection closed by remote host".

It's strange, 'cause rlogin works fine for both machines.

Furthermore, telnet command also works fine when it's
invoked from emacs shell (both elisp code and telnet being run
from emacs internal shell).

Fyi, rcp works fine, ftp doesn't, rwho works from time to time :-(.

We badly need to provide pure 8-bit channel between both our machines,
thus, we badly need telnet command work fine (rlogin even having
been run with -8 option doesn't provide some Cyrillic characters
that are control symbols for its protocol :-(
.,

Would you advice me what might be wrong?  As i remember pretty far ago
both telnet and rlogin worked well.  Unfortunately, i didn;t catch the
moment when they got failed...

*Any* suggestions would be welcome.

AlexZ.




-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 92 11:44:40 GMT
From:      Patrick John Coppock <patCoppock@avh.unit.no>
To:        comp.protocols.tcp-ip
Subject:   Mac TCP 1.1.1 for system 7.1

Does anyone know if there is  a new version of Mac TCP (probably v.1.1.1)
available for
use with the new System 7.1?

There haven't been any problems with v. 1.1. though. I just
wondered.........

Patrick Coppock
The Multimedia Lab
University of Trondheim AVH
N-7055 Dragvoll
Norway

patCoppock@avh.unit.no

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 92 12:21:06 GMT
From:      aroby@andersen.co.uk (Tony Roby)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP: Send 8 1K packets, then wait.....

barnett@grymoire.crd.ge.com (Bruce Barnett) writes:

>I am analyzing some medical networks, and I see a common pattern in
>large file transfers using FTP. Could someone tell me if this sounds
>like a bsd4.2, or bsd4.3 implementation of TCP.
 
>The sending system sends 8 1K packets. The delay is about 2
>milliseconds between packets. The last packet has a "Push"
>flag. An ack comes back. Then the sender waits a while, typically
>40-100 milliseconds, and sends out 8 more packets. 

I had a problem similar to this, where small packets are subject to a
delay.  This was a case of Nagle's small packet avoidance algorithm
(see RFC896) and may be what is causing your problem.

Tony

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 13:47:12 GMT
From:      szymon@uci.agh.edu.pl (Szymon Sokol)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs. Telnet

In article <30NOV199218421468@spades.aces.com> gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) writes:
>From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
>Subject: Re: Rlogin vs. Telnet
>Date: 1 Dec 92 01:42:00 GMT
 
>Rlogin	- Has only two active control functions, spawn (push to background)
>	  which is usally ^Z, and quit, which is ~^.  Most implementations
>	  hang if they are in a read state and the remote machine is lost
>	  and you try ~^.

I believe that ^Z is not a function of rlogin, but rather of a particular
Unix shell. On my Sun (using C-shell) I can put any process into background
by pressing ^Z. Don't know if ^Z works with rlogin under VMS.


                           Szymon Sokol
U     U  M     M  M     M  Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30
U     U  M  M  M  M  M  M  30-059 Krakow, POLAND
 UUUUU   M     M  M     M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

 "The reward of a thing well done is to have done it"  -- Emerson

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 14:55:27 GMT
From:      herbison@manage.enet.dec.com (B.J.)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs. Telnet


In article <1992Nov30.112902.28921@fallst>, tkevans@fallst (Tim Evans) writes:
>root@candle.uucp (Bruce Momjian) writes:
 
>>	1) rlogin is for unix-to-unix logins, telnet is for any tcp/ip
>>	computer
>
>rlogin is for "something-to-unix" logins.  Some (all?) of the PC
>TCP/IP packages have an "rlogin" application.

	rlogin is for "something-to-something".  Digital's UCX
	implementation allows rlogin from and to VMS systems.   

						B.J.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 15:03:49 GMT
From:      gene@aee.aee.com (Gene Kochanowsky)
To:        comp.protocols.tcp-ip
Subject:   Is NFS client for DOS availible on the internet?

Greetings:

	I am looking for a public domain NFS client for DOS on the
internet. Would anyone know where such a thing is?

Gene Kochanowsky

-- 
Gene Kochanowsky                           | "And remember ....
Associated Electronic Engineers, Inc.      |       The better you look ... 
(904)893-6741 Voice, (904)893-2758 Fax     |       the more you will see."
gene@aee.com                               |               Miss Lidia

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 15:12:50 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs. Telnet

In article <1992Nov30.112902.28921@fallst> tkevans@eplrx7.es.dupont.com writes:
}rlogin can carry your local user environment--terminal type being
}only one of what can be carried over to the remote.  Also, assuming
}proper security equivalences are set up, you can use rlogin to 
}access a remote host without a password.

Telnet has an extensible option negotiation protocol.  Recent (or
'real soon now') options include:
	environment
	authentication
	encryption
	compression
	X-Display location
	window size change

Unfortunately, many vendor telnets are woefully behind.

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

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Tue, 01 Dec 1992 15:27:10 GMT
From:      chip@osh3.OSHA.GOV (Charles Yamasaki)
To:        comp.protocols.tcp-ip
Subject:   Internet number list?

I'm not sure if this is the right place to ask this, but here goes. 
Quite some time ago I got RFC 1166 which was a complete list of assigned
Internet network numbers.  This RFC was one in a string of RFC's that
did the same over time.  I just got an updated RFC index and there is
no later version, however RFC 1166 was from July, 1990.

Is there another source for a comprehensive list like this?  I don't
have an Internet connection, so no on-line utility will work for me.

Please reply by E-Mail.  Thanks!
-- 
-----------------------+---------------------------------------------------
Charles "Chip" Yamasaki| The opinions expressed here are my own and are not
chip@osh1.OSHA.GOV     | supported or even generally accepted by OSHA. :-)
-----------------------+---------------------------------------------------

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 92 16:06:30 GMT
From:      bvs@nrc.com (Bill Versteeg)
To:        comp.protocols.tcp-ip
Subject:   Re: Server Port No....

bansal@cis.ksu.edu (Vivek Bansal) writes:


>I have written this client-server application in which basically the server
>waits on a fixed port no (5000) waiting for requests from different clients.
>Now, while the server was running I had to kill it by doing a Control-C, and
>then when I tried to rerun the server I got the message that , 
>Socket No 5000 already in use.

The bind() call associates the local side of your connection. By default,
it needs to bind to a port that has nothing else associated with it.
Apparently, port 5000 has something bound to it....
There are two reasons that this may be happening.
I assume you are using a TCP socket.

	1- If you are using the normal "spin up
		a sub-server (using fork() )" to handle
		each connection, when you kill the master daemon,
		the sub-daemons persist. They are bound to port 5000,
		so when you restart the master daemon, the port is in use.

	2- The TCP state machine description states that there is a
		"time-wait" state (in fact there are two) between
		the closure of a socket from the application end and
		when the socket structure in the kernel goes away.
		These states
		are designed to handle retransmittions of the FIN 
		packets. Furthermore, when you return from a close()
		call, the socket
		is not guarrenteed to be gone. A combination of these
		two delays may be casuing your problem

>How do I get over this problem ??? I thought once a process was killed all
>the ports used by it were immediately released ....



Look at setsockopt() and the SO_REUSEADDR option. This should
do what you want.

>Thanks...
 
>Vivek...


No troubles

Bill VerSteeg
bvs@ver.com
-- 
Bill VerSteeg
VerSteeg CodeWorks
bvs@nrc.com

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 18:08:29 GMT
From:      mitton@dave.lkg.dec.com (Dave Mitton)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Does Ethernet into Token Ring go?


In article <1992Nov30.110911.311@cpvax.cpses.tu.com>, robert@cpvax.cpses.tu.com writes:
From: robert@cpvax.cpses.tu.com
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Does Ethernet into Token Ring go?
Date: 30 Nov 92 11:09:11 CST

>At CPSES we are sucessfully bridging Ethernets using a site Token Ring
>backbone.  If you want to bridge, remember that non 802.3 packets (Ethernet
>frame format) will need to be "translated" before it gets put on the 
>token ring.  This is done by creating a fake 802.3 header and using a 
>special DDAP and SSAP field.  The bridge on the other side of the link
>recognizes the special fields and strips them off for transmission on the
>remote Ethernet.

	The translated frame does not have "fake" 802.2 header, but
one that is a _real_ Unnumbered Information frame that would be understood
by any 802 data link on that media. 
	
>This translation activity is not standardized.  

	While that is technically true, there are bits and pieces of
various specs at work here.   I suggest that anyone working with these
issues look at:
	- IEEE 802-1990; which describes the SNAP SAP
	- RFC 1042; IP datagrams over 802 Networks
	- RFC 1103; IP datagrams over FDDI

	Also be aware of the conventions of several current translational
bridges on the market.  For example the Digital DECbridges use the first
3 bytes of the SNAP PID which should normally contain the Organizationally
Unique Identifer (OUI) value, if zero to indicate a translated Ethernet
frame.   The IBM 8209 does not, and if translating into Ethernet frames
either blindly does all SNAP frames or none (for a given station if in
Autodetect mode).


	Dave Mitton
	Token Ring Program
	Networks and Communications
	Digital Equipment Corp.


-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 18:23:05 GMT
From:      mcs@unislc.uucp (Michael Sontum)
To:        comp.protocols.tcp-ip
Subject:   Re: ENOTTY from getsockopt

From article <1992Nov27.205950.26591@sal.wisc.edu>, by jones@bernie.sal.wisc.edu (Tom Jones):
> One of our programmers is getting the error return ENOTTY from
> a getsockopt call.  I don't have the source code, but here is
> the situation.  He is trying to set the tcp-level option
> TCP_NODELAY using setsockopt, so before and after that call he
> uses getsockopt to return the option setting.  Each getsockopt
> call returns the error code ENOTTY.
> 
> I know this isn't much to go on, but if anyone has seen this
> behavior and knows what is happening, I would appreciate
> hearing from them.
>
Don't know if this will help and you probably already have done this.
Look at /usr/include/sys/errno.h. Getsockopt should fail with
EBADF,ENOTSOCK,ENOPROTOOPT,ENOMEM or ENOSR. ENOTTY says that this
is not typewriter.  I am sorry but I do not know what that means
as it relates to sockets.  You might also try Steven's Network
Programming Book on page 315.

              Mike Sontum

"Never let anything mechanical know that you are in a hurry."



 

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 19:33:24 GMT
From:      dalk@login.dkuug.dk (Lars Kalsen)
To:        comp.protocols.tcp-ip
Subject:   PC/TCP from Ftp Software

Hi,

I am looking for some references on companies that use PC/TCP from
Ftp Software as a platform for Office Automation to integrate PC's in
a LAN.

We are now using PATHWORKS from DIGITAL EQUIPM. but for some reasons
we might want to change.

Does someone have a reference - then please E-mail to me.


Greetings from Denmark
Lars Kalsen



-------------------------------------------------------------------------------
Lars Kalsen, MIS-Manager
SONOFON, Skelagervej 1, 9000 Aalborg, Denmark
+45-99-367000 (tel), +45-99-367070 (fax), E-Mail : dalk@login.dkuug.dk
===============================================================================
 

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 92 22:28:38 GMT
From:      kevin@kevins.frontiertech.com
To:        comp.protocols.tcp-ip
Subject:   Re: PC/TCP from Ftp Software

hythyte

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1992 22:30:13 GMT
From:      kevin@kevins.frontiertech.com
To:        comp.protocols.tcp-ip
Subject:   Re: PC/TCP from Ftp Software

Frontier Technologies manufactures a 100% Windows DLL
TCP/IP product. Features include Ping, Telnet, FTP, NFS
Client & Server, NNTP interfact, and more. If you want a free
30 day demo, please let me know.


Regards,

Kevin McManus

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 22:37:08 GMT
From:      mikeh@cbnewsg.cb.att.com (michael p.herlihy)
To:        comp.protocols.tcp-ip
Subject:   IP Multicasting over Frame Relay


Is it possible to use the multicast feature of IP to send
a datagram to multiple LANs across frame-relay.  If not
is there another software mechanism within IP to do it.

Diagram of the problem:

						___Router---LAN(B)
		   ___________________________/
		   (			     )
LAN(A)----Router___(  Frame Relay Service    )
		   (			    )___Router----LAN(C)
		   (________________________)\
					      \__Router---LAN(D)

An endstation on LAN(A) wants to send a diagram to LANs(B-D).
Can it be done in the current environment of with PVCs connecting
all the locations?
-- 
It (the telephone) will unmake our work. No greater instrument of counter- 
revolution and conspiracy can be imagined --- Josef Vissarvonovich Stalin

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 92 22:42:14 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip, Chris Maltby <chris@suite.sw.oz.au>
Subject:   Re: NSFNet goes to hell..

Chris Maltby asks:
>So is there an ICMP return which means "absolutely no way to this
>destination"?

If you'd think about it, you would see that there couldn't be.

What you are getting back from the particular gateway is ``I don't know how to
get there.''  This is completely different from what you evidentally want,
which is for the gateway to say ``there is no way for *you* to get there.''

How is a gateway supposed to know this?  You are assuming that all gateways
know of all possible Internet routes.  This is a fantasy, and with the
proliferation of firewalls there is a corresponding proliferation of IP routes
which are not known, or available only to certain hosts or networks.  So,
you're requiring that every gateway in the world know about every firewall
too.  That's just not practical.

The only thing that can conclude ``absolutely no way to this destination'' is
the end user or the end user's application.  If all the gateways you know to
try say ``I don't know how to get there'', then it is reasonable to assume
that you can't get there.  Most people only have one or two gateways to talk
to, so this isn't a big deal.  Usually, though, you only make such a decision
on a connection attempt.  If, on the other hand, you were connected and you
get a ``I don't know how to get there'', then it is quite possible it is a
brief outage (remember -- TCP/IP was designed to survive in nuclear war!) and
a new route will appear shortly.

That's why the behavior of older BSD implementations is so brain-damaged; it
is eager to declare connections dead on the basis of outages of a second or
less!

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Dec 1992 23:19:36 GMT
From:      harlan@cms-stl.com (Harlan Stenn (PFCS Corporation))
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   tcpdump and rarpd wanted for HP9k7xx 08.07

Anybody have a working tcpdump or rarpd for HPUX 08.07 on a '720?

I'm hoping I won't have to have an experience getting the bpf stuff
working on this platform...

Harlan

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 92 23:24:46 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

In article <chris.723162756@suite.sw.oz.au> chris@suite.sw.oz.au (Chris Maltby) writes:
>So is there an ICMP return which means "absolutely no way to this
>destination"?

The one and only ICMP destination unreachable message says, "This
router knows of absolutely no way to this destination."  Since routers
are not omniscient, no router can know if there is *any* way to the
destination; all it can know is that *it* doesn't know the way.  When
a router doesn't know how to send a particular packet towards its
destination, rather than just send it off in a random direction --
which would be both silly and dumb -- the router drops the packet.
Having dropped the packet, it can either tell the source that it
dropped the packet (via an ICMP destination unreachable) or it can
remain quiet.  The routers you are dealing with politely send a
notification as "a courtesy".

Some TCP implementors mistakenly thought the "I don't know where to
send the packet you sent" indication in an ICMP destination
unreachable meant "there's no way for you to send that packet to that
destination," so they immediately abort the TCP connection.  It sounds
like this is the source of your problem.  Since the distributed
routing database is unsynchrnonized while a network is recovering from
a change in topology, a particular router may temporarily find itself
with no routing information to a particular destination and will be
forced to drop the packet.  There's just no avoiding it.

>"I'm dropping this datagram because it's the best thing under the circumstances
>but I'm not making any statement about the likelihood of sucess or failure if
>you try again." If that is Network Unreachable, how are they to say
>"forget it, I have no idea how to get there"?

To sum up in a nut shell, from any given router's point of view,
there's no difference between those two statements.  A router cannot
say "Give up, it will *never* work" without precognition.

						don provan
						donp@novell.com

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 92 23:40:49 GMT
From:      wiltzius@anduin.ocf.llnl.gov (Dave Wiltzius)
To:        comp.protocols.tcp-ip,comp.graphics
Subject:   MAGIC test-bed w/visualization


In the June 29, 1992 Communications Week I read an article about
the Multidimensional Applications and Gigabit Internetwork
Consortium (MAGIC) test-bed network.  I am very interested in
this type of application (terrain visualization), including the
prototype "image server" at Lawrence Berkeley Lab.  Other
particpants are DEC, Northern Telecom, Sprint, Minnesota
Supercomputer Inc., Earth Resources Observation Systems (EROS)
and the U.S.Army's Future Battle Lab.

Can anyone provide additional information or leads?

Please email responses.  Thanks.
  Dave Wiltzius
  Lawrence Livermore National Lab
  Livermore, CA
  (510) 422-1551
  wiltzius@llnl.gov

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Dec 92 00:13:17 GMT
From:      guru@camelot.bradley.edu (Jerry Whelan)
To:        comp.unix.programmer,comp.unix.questions,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Access to ARP protocol from a user program?

	I'm hoping I'm just suffering from ignorance here.

	I need to develop a server that given either a MAC address or an
IP address returns the corresponding address.  I understand that the
ARP protocol works along these lines (at least given an IP it returns a
MAC).  Rather than develop my own protocol on top of ip/tcp (actually
probably ip/udp) I'd like to use something that already exists.  However
I can't seem to find any documentation as to how to go about doing ARP
(and probably RARP??) calls.  Can it be done the way I want to do it
and if so where do I find out how to do it?
	BTW, if it matters this application will run under 386 SVR4 and
SunOS 4.?.?.

-------------------------------------------------------------------------------
``written by a drunken insane pathological liar''        guru@stasi.bradley.edu

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1992 00:13:40 GMT
From:      John@Johns.FrontierTech.COM (John F. Moehrke (414-284-5559))
To:        comp.protocols.tcp-ip
Subject:   Tech?: BOOTP over SLIP or PPP

Does anybody know if there is a description of how to work BOOTP over
protocols such as SLIP or PPP. It seems this should work but the problem
is that there is a field in the BOOTP header that contains the physical
layer type, and these numbers are defined as the hardware types for ARP.
Since SLIP and PPP do not use ARP, they do not have numbers.

The second problem is that the BOOTP header also contains a field
for the physical layer address (i.e. Ethernet address). PPP and SLIP do
not have an physical layer addresses. What does the BOOTP server have
to base it's IP address suggestion on?



-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1992 00:24:46 GMT
From:      garyh@sdsc.edu (Gary Hanyzewski)
To:        comp.protocols.tcp-ip
Subject:   TCP-UDP/IP application design questions

	I'm trying to design an TCP-UDP/IP system which will allow 
	a number of remote 'clients' to connect to a 'server' that
	periodically produces a number of data-sets.  Each 'client'
	indicates which one-and-only one data set it want's and the
	server will send this data-set everytime it is generated.  I've
	toyed with the idea of a server deamon talking to both the
	data-generation program and the remote clients, but I
	can't figure out the details of how the data-generator 
	communicates the data to the deamon(s).  My current thoughts
	use Berkeley sockets ( TCP or UDP ) and go something like this.

	-- Deamon process starts up and waits for connections from both
	   the remote clients and the data-generation client.
	-- The data-generation client sends a list of available
	   data-sets to the deamon and then begins data-generation.
	-- Remote client(s) connect to the deamon and are sent a list 
	   of available data-sets from which they choose 1.  The deamon
	   records the choice and forks() a child process to handle all
	   further communication with that remote client.
	-- As data-sets are ready, the data-generation client contacts 
	   the deamon with the sets name.  If the deamon knows of a 
	   client requesting that data, it accepts the transfer from the
	   data-generator and sends it to the appropriate client otherwise
	   it refuses the transfer and the data-generator continues to 
  	   work.   

	My problems are 

	1.) How does the data-generation client know which fork()ed deamon
	    to send it's data to?
	2.) The whole system seems kind-of kludgy.

	Does anyone have any suggestions on how to better implement 
	this system given the restrictions that I can't fork() the
	data-generation process due to it's overwhelming size.

	Thanks for any suggestions/ pointers to references..

	Gary H.
---
////////////////////////////////////////////////////////////////////////
         Gary Hanyzewski                | "... There are more things in
         garyh@bashful.sdsc.edu    	|      heaven and earth than
         (619)534-5129                  |      are dreamt of in your 	
     >>                       <<        |      philosophy ...."
////////////////////////////////////////////////////////////////////////


-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1992 00:44:12 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Tech?: BOOTP over SLIP or PPP

In article <1fgv3kINNdgn@spool.mu.edu> John@Johns.FrontierTech.COM (John F. Moehrke (414-284-5559)) writes:
>It seems this should work but the problem is that there is a field in the
>BOOTP header that contains the physical layer type, ...

It does work.  Just ignore the physical layer type code and address.
The BOOTP server has to base its IP address on the port of the SLIP
server on which the BOOTP request arrived.  In other words, the BOOTP
server pretty much has to be on the SLIP server.

Of course, once the SLIP client has an IP address, it can send out a
BOOTP request that has the hardware address field filled in, and the
BOOTP server can use that information.  (I haven't heard of any imple-
mentations that do this.)

As far as I can tell, this is the only way BOOTP over SLIP can work.
It is quite useful anyway.

-- 
Stephen Trier                                    It's either very surprising
Network Services Engineering, IRIS/INS/Telecom    or not surprising at all.
Case Western Reserve University                    Let me think about it.
trier@ins.cwru.edu                                       - Palmer Davis

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1992 14:08:17 +0800
From:      comrade@uniwa.uwa.edu.au (Peter Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs. Telnet

tkevans@fallst (Tim Evans) writes:
>rlogin can carry your local user environment--terminal type being
>only one of what can be carried over to the remote.  Also, assuming
>proper security equivalences are set up, you can use rlogin to 
>access a remote host without a password.

But then, telnet propagates your term type.  I have been led to believe
that rlogin is kinder to the network (???) but I do know that you can
run zmodem far more reliably through an rlogin session than a telnet
session (required if you generally use a dialup on a terminal server).

Peter
-- 
email:  comrade@uniwa.uwa.edu.au   snail:  Peter Cooper
fax:    +61 9 380 1041                     Guild of Undergraduates
phone:  +61 9 380 3929                     University of Western Australia
"It was the banana that did it!" - Julia Marley

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Dec 92 08:37:50 EST
From:      foudil@npac.syr.edu (Kamal Foudil-Bey)
To:        comp.protocols.tcp-ip
Subject:   How to set up system for tip

I am trying to use tip do dial in and out of my site through
a modem. I am able to dial out but as soon as the connection is
established I received a few legible characters and a lot of
garbage ....I would appreciate if anyone could help me
with the necessary setup
My hardware : IPC station (Sun Microsystem) .
	1200 passwd robotics.
	Sun os 4.1.2
thanks

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Dec 1992 03:43:13 GMT
From:      "Michael" <wk01687@worldlink.com>
To:        comp.protocols.tcp-ip
Subject:   Re : Server Port No...

---
\I have written this client-server application in which basically the server
\waits on a fixed port no (5000) waiting for requests from different clients.
\Now, while the server was running I had to kill it by doing a Control-C, and
\then when I tried to rerun the server I got the message that , 
\Socket No 5000 already in use.
\
\How do I get over this problem ??? I thought once a process was killed all
\the ports used by it were immediately released ....
\
\Thanks...
\
\Vivek...
------

If there are clients still attached to the port (ie connections are still
open) you will not be able to bind to it until all of the clients close
down.  You didn't say what kind of system you are using but if you can,
run "netstat -a" and look for your port number.  You should be in a
FIN WAIT 2 state (waiting for REMOTE shutdown).

Michael Jamet


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1992 15:52:08 -0600
From:      mgriffin@matt.ksu.ksu.edu (Mark Griffin)
To:        comp.protocols.tcp-ip
Subject:   Help setting up TCP/IP WIN/3B

We are trying to set up TCP/IP WIN/3B on an AT&T 3B2/600 and a 3B2/1000.
It is release 2.1 of the TCP/IP software.  We already have Starlan 3.2 running
on the ethernet with no trouble.  The 3b2/600 runs Unix 3.1.1 and the 3b2/1000
runs Unix 3.2.3.  So far the loopback test of `telnet me` works fine, but
we cannot telnet to a remote address.  We are not on internet right now, but	will be in the future.  In the meantime, does it really matter how our
machines are addressed?  And, can we run Starlan and TCP/IP in conjunction over
the same ethernet.  I seem to think so, but the documentation doesn't 
specifically say so.  Thanks in advance for any help.

-- 
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  .
Mark Griffin, Sys Admin, Fort Hays State University      |It is always better to
Internet:mgriffin@matt.ksu.ksu.edu Bitnet:mgriffin@ksuvm |do, than be done to.
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  .

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 05:54:00 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Terminal Server Recommendations?

In article <1992Nov24.172942.19127@pbs.org> esiewick@pbs.org writes:
>PBS is attempting to connect a large number (several thousand) sites on
>one data network via VSAT satellite.  At the satellite-remote site (300+)
>level we need to connect modems to terminal servers to data servers to 
>satellite communications equipment.  All is going fine except the terminal 
>server we've begun the project with cannot/does not perform SLIP and UUCP 
>properly, at least not concurrently.  Yes, these would seem to be very 
>simple, common tasks expected of any such product in the marketplace.

The description of your application is unclear. Especially the use of
UUCP and terminal server in the same breath. This community could be
much more helpful if we could understand your application.

Do you have 300+ remote sites, each of which accepts dial-in connections
over the public telephone network, which connections then go over the
satellite network to a file server at a central location ?

Or is the modem link really the satellite connection ? And the terminal
servers are all sitting at the central location ?

Why are you using SLIP and UUCP ? Why not all PPP ? Are any of you modem
ports used for "real async" to a telnet client or is it all
IP-over-async ? (In the latter case, the term terminal server is really
a misnomer, and what you are after is a full-blooded "network access
server".)
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 11:53:32 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   Dialup Slip 4 Sun,SysVR4, PC and Mac

Hi folks,

The subject basically says it all. I'm looking for dialup slip
implementations for the above architectures. If there is such a thing as
dialup ppp for these I'd be even more delighted to hear from you.

	Thanks a lot

			-Torsten
--
Torsten Beyer                      	mail	     : tb@Materna.DE
Dr. Materna GmbH		   	vox humana   : +49 231 5599 225
Vosskuhle 37, D-4600 Dortmund	   	fax machina  : +49 231 5599 100
   "Once in a moment the SUN goes down, protect and survive" -- Runrig

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 13:56:18 GMT
From:      russ@xylogics.com (Russel M. Lamoreaux)
To:        comp.protocols.tcp-ip
Subject:   Re: Server Port No....


>>I have written this client-server application in which basically the server
>>waits on a fixed port no (5000) waiting for requests from different clients.
>>Now, while the server was running I had to kill it by doing a Control-C, and
>>then when I tried to rerun the server I got the message that , 
>>Socket No 5000 already in use.
 
>>How do I get over this problem ??? I thought once a process was killed all
>>the ports used by it were immediately released ....
>
>
>
>Look at setsockopt() and the SO_REUSEADDR option. This should
>do what you want.
>
>>Thanks...
 
>>Vivek...
>
>
>No troubles
>
>Bill VerSteeg
>bvs@ver.com

You can also use SO_LINGER. 

    {
	struct linger linger;

	linger.l_onoff = 1;
	linger.l_linger = 0;
	if (setsockopt(s, SOL_SOCKET, SO_LINGER, (char *)&linger,
         	       sizeof(linger)) < 0) {
            perror("setsockopt SO_LINGER");
	    exit(-1);
        }
    }

 man setsockopt should give you the details!

  Russ Lamoreaux
  russ@Xylogics.COM


















-- 
  --------------------------------------------------------------------
  Russ Lamoreaux                                     russ@Xylogics.COM
  Xylogics, Inc.                                  
  53 Third Ave.                                   (617) 272-8140 x-253

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 15:01:14 GMT
From:      rene@primel.informatik.rwth-aachen.de (Rene Jonas)
To:        comp.protocols.tcp-ip
Subject:   Socket-Size for various machines (SUN, SGI, Cray)

Hi there !

Today I read something about the default Socket-size (determines the sliding
window for TCP/IP) on various machines (SUN, CRAY, SGI).

Could the autor of this post repost it to this group or to my E-mail.

Thanks,
Rene

Rene Jonas
E-mail : rene@primel.informatik.rwth-aachen.de

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 16:02:34 GMT
From:      dcarros@rcsuna.gmr.com (Donald Carros )
To:        comp.protocols.tcp-ip
Subject:   BOOTP on many H/W platforms?

I need some help. We are forced to support a large building network
that in turn is part of a much larger campus network. We support
three protocols TCP/IP, DECnet and IPX, routed over both Wellfleet
and CISCO routers. Our planned building network will support over 
70 subnets in the IP environment. 

On the hardware side imagine your worst dreams. SGI's, Suns, IBM's,
HP's, DEC's (running Ultrix) and PC's (of all variety). We are
contemplating running BOOTP off dedicated servers.

Has anyone attempted such an installation?
Can all of the above platforms be supported using BOOTP?

Thanks in advance.

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Dec 1992 16:34:57 GMT
From:      tendico@hubcap.clemson.edu (Todd Endicott)
To:        comp.protocols.tcp-ip,comp.sys.mac.programmer
Subject:   MacTCP Question

Hello all. I'm writing an application that needs to incorporate MacTCP,
and I've run into a bit of a hitch. In the TCPInit() routine, a call is
made to PBOpen() with a device driver name of ".ipp". Does anyone know
where I might find such a creature, or am I just thickly missing
something, or what? Reply in the manner you see fit, and thanks.
-- 
Todd Endicott
tendico@hubcap.clemson.edu					 "Yow!"

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1992 19:14:54 GMT
From:      kevin@kevins.frontiertech.com
To:        comp.protocols.tcp-ip
Subject:   Free Windows TCP/IP

Frontier Technologies manufactures Super-TCP for Windows.

Features include 100% DLL or TSR capability, color TN3270
or VT220, client server FTP&TFTP, SMTP/POP2&3 email,
NNTP, interactive Talk, NFS client & server, R protocols,
SNMP agent, extendable MIBS, RPC/XDR API, Netbios, LPD/LPR,
SLIP/PPP, X.25, Modem server! Support NDIS,ODI,ASI,PDS drivers!

Free demo available! Send telephone or fax number today!

email reply to: Kevin@FrontierTech.Com
10201 N. Port Washington Rd.
Mequon, WI 53092
Telephone: 414-241-4555 ext. 217
Fax: 414-241-7084

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Dec 1992 20:13:09 GMT
From:      automate@netcom.com (Competitive Automation)
To:        comp.protocols.tcp-ip
Subject:   Socket question: On which interface was datagram received?

Suppose you have a machine with 2 (or more) network interfaces.
How, using sockets (or TLI for that matter) do you accept
packets from both interfaces, and yet determine on which
interface the packet arrived. I can see no way to do this
using sockets viz:

1. Create a single socket and bind it to INADDR_ANY. This
   will get packets from both interfaces, but you can't
   determine which.

2. Create separate sockets for each interface. You still
   can't listen for packets which were broadcast to
   "pseudo-address" 255.255.255.255. At least on SUN's
   implemntation, you can't bind to that address.
   (You get "Can't assign requested address" system error).

It is true that if you know the subnet specific broadcast
address you can listen for those packets. E.g If the
interface has an address 192.9.200.1 you can listen
on 192.9.200.0 (assuming no subnetting). You will
also have to create a separate socket to get packets addressed
to 192.9.200.1.But you still don't get packets addressed
to 255.255.255.255. Also it seems ridiculously complicated
to have to create 4 sockets just so you can determine
the interface where the packet arrived.

Is this just a SUN/BSD4.x specific problem?


Rob Stevens. Competitive Automation.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 20:31:58 GMT
From:      johnson@tigger.jvnc.net (Steven L. Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Tech?: BOOTP over SLIP or PPP

trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:

>Of course, once the SLIP client has an IP address, it can send out a
>BOOTP request that has the hardware address field filled in, and the
>BOOTP server can use that information.  (I haven't heard of any imple-
>mentations that do this.)

Although I suppose it would be possible to use the IP address as
a dummy hardware address, I think you probably meant that it
could fill in the client ip address (ciaddr) field in the bootp
request (still leaving the hardware address and type 0).  A
standard bootp server then could process it.

One bootp client that does work this way is KA9Q.  Although it
might actually be a bug rather than a feature.  If the first
reply is missing the magic cookie for the vendor specific
extensions reserved in RFC 951, and later standardized in RFC 1048,
KA9Q reports an error.  But it has already configured the IP
address and uses this in subsequent retries.

-Steve

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 20:34:31 GMT
From:      chuck@npdiss1.StPaul.NCR.COM (Charles Rissmeyer)
To:        comp.protocols.tcp-ip
Subject:   Sending to Compuserve via Internet

Hi - Does anyone here know what addressing to use to send email to a
user on Compuserve via the Internet?  I remember once seeing that Compuserve
has a gateway to the internet, but I don't remember the addressing.

Something like 75115,1366@compuserv.com perhaps?

Thanks,

Charles (Chuck) Rissmeyer    KE0VG
(612) 638-7669  (VP 652-7669) -  charles.rissmeyer@StPaul.NCR.COM
NCR - An AT&T Company             NCR  CCS-PM&S NPD St. Paul

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1992 21:38:47 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Tech?: BOOTP over SLIP or PPP

In article <1992Dec2.203158.6149@tigger.jvnc.net> johnson@tigger.jvnc.net (Steven L. Johnson) writes:
>...I think you probably meant that it could fill in the client ip address
>(ciaddr) field in the bootp request (still leaving the hardware address
>and type 0).

Sorry!  That's exactly what I meant, though not what I wrote.

>One bootp client that does work this way is KA9Q.  Although it
>might actually be a bug rather than a feature.

Interesting.  Are there any BOOTP servers that look at the ciaddr field?

-- 
Stephen Trier                                    It's either very surprising
Network Services Engineering, IRIS/INS/Telecom    or not surprising at all.
Case Western Reserve University                    Let me think about it.
trier@ins.cwru.edu                                       - Palmer Davis

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Dec 92 21:55:56 GMT
From:      kenneth@bnrmtl.bnr.ca (Ken Rosenfeld)
To:        comp.protocols.tcp-ip
Subject:   TLI: t_accept returns TLOOK (why?)

I'm writing a server using the TLI library for TCP
(on a Sun).

The server executes the following in a loop:

  t_listen(listenfd, ...)        /* receive connect indication */
    
  t_accept(listenfd, newfd, ...) /* accept the call */

There is a case where this code does not work: Two clients
make connect requests before the server executes the t_listen().
The t_listen() then receives the first connect indication.
The t_accept() fails, however, with t_errno = TLOOK.  
A subsequent call to t_look() returns the T_LISTEN event.

Apparently this is correct behaviour.  The man page states:

 ... t_accept() will  fail  and  set
 t_errno to TLOOK if there are indications (such as a connect
 or disconnect) waiting to be received on that endpoint.

The consequences for the program are grave.  The program must
do a t_listen() to receive the second connect indication, then
restart the t_accept().  The second connect indication must later 
be t_accepted.

In theory, there may be many pending connect indications.  A
t_listen() must be executed for each indication before the
t_accept can succeed.  It's also possible for the t_accept
to return a TLOOK error, event T_DISCONNECT, for one of the
received (but not yet accepted or rejected) connect indications.

I've looked at the excellent UNIX Network Programming book.
The code does not handle the case of a t_accept() returning
a TLOOK error, with event T_LISTEN. On page 361:

    if (t_accept(listenfd, newfd, callptr) < 0) {
        if (t_errno == TLOOK) {
            /*
             * An asynchronous event has occurred.  We must have
             * received a disconnect.  Go ahead and call t_rcvdis(),
             * then close the new file descriptor that we opened
             * above.
             */

            if (t_rcvdis(listenfd, (struct t_discon *) 0) < 0)
                err_sys("t_rcvdis error");
            if (t_close(newfd) < 0)
                err_sys("t_close error");
            return(-1); /* return error to caller */
        }
        err_sys("t_accept error");

What were the designers of TLI (and XTI) thinking of?

Ken Rosenfeld
Bell-Northern Research
kenneth@bnr.ca


-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 22:20:07 GMT
From:      jdt@voodoo.boeing.com (Jim Tomlinson)
To:        comp.protocols.tcp-ip
Subject:   read->fread with sockets; gotchas?


I'm reworking our application's socket communication code to use
fread/fwrite rather than read/write , so as to enhance our
portability.  What problems can I expect to crop up from this change.
Our higher-level 'read' and 'write' functions will try to hide the
effects of buffering from the programmer, but I'm sure there's
something here I'm not thinking of that'll bite us.  Any thoughts?
-- 
Jim Tomlinson  jdt@voodoo.ca.boeing.com            "Two is one." - Dizzy

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 92 23:08:23 GMT
From:      sss@scammell.ecos.tne.oz.au (Steve Silver)
To:        comp.protocols.tcp-ip
Subject:   Byte Offset for well known ports

To all TCP/IP gurus.

I have been studying the IP and TCP RFCs (ie 791 & 793) to obtain the
byte offset (position) of the well known ports. In particular, 
TELNET (port 23) and FTP (port 21).

I have noticed that the ports above 1024 are for incoming Telnet or FTP.
Can you confirm where the incoming ports start from.

Thank you for your help.


-- 
Steve Silver         sss@scammell.ecos.tne.oz.au

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Dec 1992 23:28:31 GMT
From:      apple.com (Ben Beasley)
To:        comp.protocols.tcp-ip,comp.sys.mac.programmer
Subject:   Re: MacTCP Question

The .ipp driver is installed with the MacTCP software.
Regards,
        Benjamin Beasley
In article <1992Dec2.163457.27149@hubcap.clemson.edu>, tendico@hubcap.clemson.edu (Todd Endicott) writes:
> 
> Hello all. I'm writing an application that needs to incorporate MacTCP,
> and I've run into a bit of a hitch. In the TCPInit() routine, a call is
> made to PBOpen() with a device driver name of ".ipp". Does anyone know
> where I might find such a creature, or am I just thickly missing
> something, or what? Reply in the manner you see fit, and thanks.
> -- 
> Todd Endicott
> tendico@hubcap.clemson.edu					 "Yow!"

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Dec 1992 00:14:13 GMT
From:      kenh@leps5.phys.psu.edu (Ken Hornstein)
To:        comp.protocols.tcp-ip
Subject:   Re: PC/TCP from Ftp Software

In article <ByMp8p.HKx@wm.estec.esa.nl> news@wm.estec.esa.nl writes:
>One problem with winqvt tho'; if you ftp to an IBM mainframe you need
>to specify your account after you login. WINQVT doesn't have the account
>command, so you can't ftp to a mainframe from this.

It doesn't even have a "quote" command?  How silly.

--Ken

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 92 00:24:08 GMT
From:      Karl_Kleinpaste@cs.cmu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Sending to Compuserve via Internet

chuck@npdiss1.stpaul.ncr.com writes:
   Something like 75115,1366@compuserv.com perhaps?

75115.1366@compuserve.com

Note `,' -> `.' in userid, and terminating E in compuservE.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 92 02:58:18 GMT
From:      mly@atalanta.adoc.xerox.com (Richard Mlynarik)
To:        comp.protocols.tcp-ip
Subject:   Re: Choosing port numbers for TCP servers

In article <Byn8r6.48H@micrognosis.co.uk> jharuni@micrognosis.co.uk (Jonathan Haruni) writes:

   I would like to know how to configure a server in the "services" file,
   or in this NIS services database if it is in use.  Some facts I have
   collected from unreliable sources are:

   [...]

Magic numbers stink.

Use TCPMUX (RFC1078) and choose a guaranteed-globally-unique protocol
name like "version-1.my-protocol.micrognosis.co.uk"

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Dec 1992 06:33:22 GMT
From:      clfung@uxmail.ust.hk (Fung Chi Leung)
To:        comp.protocols.tcp-ip
Subject:   Multicast in SUNOS 4.1.3

Our system has upgraded to SUNOS 4.1.3 recently. As I heard from the news, 
it can support multicasting, right?  Can anyone out there give me any examples
or guides of how to program the multicasting functions?  

Thanks in advance.

Leung

/M\/M\/M\/M\/M\/M\/M\/M\/M\/M\/M\/M\/M\/M\/M\/M\M\/M\/M\/M\
Fung Chi Leung                                 
E-Mail: clfung@uxmail.ust.hk
Phone:	358 7022
Addr:	Room 641 PG Hall, HKUST, Clear Water Bay, Hong Kong
       ___                ___   
  /   /__   /   /  /\  / / __ 
 (__ (___  (___/  /  \/ (__/
\W/\W/\W/\W/\W/\W/\W/\W/\W/\W/\W/\W/\W/\W/\W/\W/W/\W/\W/\W/

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Dec 1992 15:38:39 GMT
From:      denny@alisa.com (Bob Denny)
To:        comp.protocols.tcp-ip
Subject:   MISLEADING: "Free Windows TCP/IP"

If this isn't advertising, I don't know what is! And it's NOT free, only a
demo is...

In <1fj1vlINNa8t@spool.mu.edu> kevin@kevins.frontiertech.com writes:

> Frontier Technologies manufactures Super-TCP for Windows.
> 
> Features include 100% DLL or TSR capability, color TN3270
> or VT220, client server FTP&TFTP, SMTP/POP2&3 email,
> NNTP, interactive Talk, NFS client & server, R protocols,
> SNMP agent, extendable MIBS, RPC/XDR API, Netbios, LPD/LPR,
> SLIP/PPP, X.25, Modem server! Support NDIS,ODI,ASI,PDS drivers!
> 
> Free demo available! Send telephone or fax number today!
> 
> email reply to: Kevin@FrontierTech.Com
> 10201 N. Port Washington Rd.
> Mequon, WI 53092
> Telephone: 414-241-4555 ext. 217
> Fax: 414-241-7084
_______________________________________________________________________________
Robert B. Denny                                           voice: (818) 792-9474
Alisa Systems, Inc.                                         fax: (818) 792-4068
Pasadena, CA                         (denny@alisa.com, ..uunet!alisa.com!denny)

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Dec 1992 18:20:43 GMT
From:      tga@oar.net (Germann Associates)
To:        comp.protocols.tcp-ip
Subject:   Re: Sending to Compuserve via Internet

In article <1564@npdiss1.StPaul.NCR.COM> chuck@npdiss1.StPaul.NCR.COM (Charles Rissmeyer) writes:
>
>Something like 75115,1366@compuserv.com perhaps?
>

Try 75115.1366@compuserve.com
         ^              ^
Note the changes.


>Thanks,
>
>Charles (Chuck) Rissmeyer    KE0VG
>(612) 638-7669  (VP 652-7669) -  charles.rissmeyer@StPaul.NCR.COM
>NCR - An AT&T Company             NCR  CCS-PM&S NPD St. Paul


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

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Dec 1992 21:44:28 GMT
From:      b.watson@uws.edu.au
To:        comp.protocols.tcp-ip
Subject:   why can't I just keep reading from a socket?

Hi,
   I have just started to experiment with sockets.  I have writen a
simple client and it all seems to work but fails for no apparent
reason in the middle of the read loop.  I have:
 
while (1) {
  if (c |= '\r')
    fputc(c, fp);
  len = read(s, &c, 1);
  if (len <= 0)
    break;
}
 
I know this is not very nice but it should work??  It works some
time and others it does not.  The read just return -1 at a random
point in time and the loop exits|
 
Is there something simple that I am missing, perhaps when I create
the socket, or should I go buy a socket programming book and start
from scratch?
 
I am running on an RS/6000 with AIX 3.1.5 and talking to servers
on various platforms.
 
---
  Brian Watson
  Programmer, Computing Centre
  University of Western Sydney, Macarthur
  Internet: b.watson@uws.EDU.AU

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 02:00:37 GMT
From:      rorem@bert.eecs.uic.edu (Doug Rorem)
To:        comp.protocols.tcp-ip
Subject:   Re: MISLEADING: "Free Windows TCP/IP"

denny@alisa.com (Bob Denny) writes:

>If this isn't advertising, I don't know what is! And it's NOT free, only a
>demo is...
 
>In <1fj1vlINNa8t@spool.mu.edu> kevin@kevins.frontiertech.com writes:
 
>> 
>> Free demo available! Send telephone or fax number today!
        ****

I liked the fine print too... Nothing like a misleading 'teaser'
subject line to get people to read the ad. No wonder people
get upset about advertising on the net.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1992 12:03:09 -0600
From:      mgriffin@matt.ksu.ksu.edu (Mark Griffin)
To:        comp.protocols.tcp-ip
Subject:   what tcp-ip software to run

We want to run tcp-ip on some AT&T 3B2's running UNIX System V 3.2.
What are some of the better versions of tcp-ip to run on these systems.
Free or low cost is best, but will consider more expensive alternatives
if we have to.  Please indicate where I can get this software too if 
possible.  Thanks for helping us that are new to networking and the 
internet.

-- 
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  .
Mark Griffin, Sys Admin, Fort Hays State University      |It is always better to
Internet:mgriffin@matt.ksu.ksu.edu Bitnet:mgriffin@ksuvm |do, than be done to.
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  .

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 03:09:51 GMT
From:      oleg@gd.cs.csufresno.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Choosing port numbers for TCP servers

In article <Byn8r6.48H@micrognosis.co.uk> jharuni@micrognosis.co.uk (Jonathan Haruni) writes:
>I would like to know how to configure a server in the "services" file,
>or in this NIS services database if it is in use.  Some facts I have
>collected from unreliable sources are:
>
>   - Port numbers 0-1024 are for servers running as root
>   - Port numbers 5001 and up are reserved for servers, root or otherwise.
>
>From (bad) experience, I have also found (on a SunOS 4.1.2 machine) that
>port numbers 1025-5000 are assigned in rotation by the system to the client
>side of each successful TCP connection, so although I haven't seen it written
>anywhere, I can say that (on Sunos 4.1.2)
>
>   - Port numbers 1025-5000 are reserved for the system
>
>Thus I would tend to conclude that in configuring a new TCP service, I should
>choose a port number over 5000.
>
>This stinks.  I'm relying on information which I have gleaned from header
>files and from practical experience.  Can someone direct me to a fairly
>widespread written authority which says that port numbers over 5000 are
>guaranteed to work and, more interestingly, that port numbers between 1024
>and 5000 are not available for use by servers and are reserved for the system ?
>Are the "facts" I have supplied here fairly portable or are they SunOS
>specific ?
>
>Where is it documented that one *MUST NOT* use port numbers such as, "3000"
>for one's servers ?
>
/usr/include/netinet/in.h

/*
 * Ports < IPPORT_RESERVED are reserved for
 * privileged processes (e.g. root).
 * Ports > IPPORT_USERRESERVED are reserved
 * for servers, not necessarily privileged.
 */
#define IPPORT_RESERVED         1024
#define IPPORT_USERRESERVED     5000


>
>PLEASE NOTE: This article is posted to a few groups, but follow ups are to
>             comp.protocols.tcp-ip.  Please don't post to the other groups.
>             If you mail to me, I may use your mail in a summary to c.p.tcp-ip
>             and I will credit you unless you ask me not to.
>
>Thanks and regards,
>
>Jonathan Haruni
>jharuni@micrognosis.co.uk

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 08:50:31 CDT
From:      karh@pa621a.inland.com
To:        comp.protocols.tcp-ip
Subject:   Time/Date Servers

Hi all,

I have a simple question.  How does one get and translate the data/time from 
one of those time services?  The service has a port of 13 or 37 and protocols
of TCP and UDP (on my systems).  Iv'e managed to get a response by sending a
dummy message, yet I can't make out what its sending back.

I don't have any Manuals or RFC's, help me.

-Bill
-----------------------------------------------------------------------------
Opinions expressed    | William D. Karh           |       InterNet:
are not those of my   | Dept. Process Automation  |  karh@pa881a.inland.com
employer...           | Inland Steel FPC          |


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1992 08:40:05 GMT
From:      M.Gream@uts.EDU.AU (Matthew Gream)
To:        comp.protocols.tcp-ip
Subject:   TCP_URG, does it lower security?


 I thought of this a few months ago, when I was investigating the Xinu
tcp/ip implementation. It seems that Urgent TCP data makes it easier
for packet injection, since sequence number checking does not occur
with the urgent part of the datagram. Thus you could construct a 
datagram with malicious data and send it along with URG set , and
presto its in.
 
  In fact, if you knew there was a connection between two machines, it
would be quite easy to storm a wide range of ports and have your data
injected (ones 513 or 23, and the other side is _probably_ <4096).

 Is this right or is there something fundamental I am overlooking? 

Matthew.
--  ___
  Matthew Gream - email: M.Gream@uts.EDU.AU
    ---

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 08:48:12 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast in SUNOS 4.1.3



 >Our system has upgraded to SUNOS 4.1.3 recently. As I heard from the news, 
 >it can support multicasting, right?  Can anyone out there give me any examples
 >or guides of how to program the multicasting functions?  

 Leung

i thought it was only supported by sun in SunOS 5/Solaris

but you can get the README from the stanfrod/xerox release of
multicast for SunOS...
on gregorio.stanford.edu
in
ivmtp-ip/pmulti-sunos41x.tar.Z


and lots of source for programs that do thinbgs on multicast
sockets...
like join groups and send and receive UDP On them

j.

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 12:03:12 GMT
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: ENOTTY from getsockopt

In comp.protocols.tcp-ip, article <1992Nov27.205950.26591@sal.wisc.edu>,
  jones@bernie.sal.wisc.edu (Tom Jones) writes:
> One of our programmers is getting the error return ENOTTY from
> a getsockopt call.  I don't have the source code, but here is
> the situation.  He is trying to set the tcp-level option
> TCP_NODELAY using setsockopt, so before and after that call he
> uses getsockopt to return the option setting.  Each getsockopt
> call returns the error code ENOTTY.
> 
The most likely source of the problem is that the code in question 
uses stdio before printing the error. Stdio checks if a file descriptor
is a tty by calling isatty(). This sets errno to ENOTTY if it isn't.

-- 
Alimony is like buying oats for a dead horse.
                                       - Arthur Baer -
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 13:46:06 GMT
From:      dbasinge@ucs.indiana.edu (D. Michael Basinger)
To:        comp.protocols.tcp-ip
Subject:   Re: MISLEADING: "Free Windows TCP/IP"

In article <1992Dec4.020037.29815@bert.eecs.uic.edu> rorem@bert.eecs.uic.edu (Doug Rorem) writes:
>denny@alisa.com (Bob Denny) writes:
>
>>If this isn't advertising, I don't know what is! And it's NOT free, only a
>>demo is...
 
>>In <1fj1vlINNa8t@spool.mu.edu> kevin@kevins.frontiertech.com writes:
 
>>> 
>>> Free demo available! Send telephone or fax number today!
>        ****
>
>I liked the fine print too... Nothing like a misleading 'teaser'
>subject line to get people to read the ad. No wonder people
>get upset about advertising on the net.

I called and wasn't offered a demo version, only pricing info.
Sound like a good product, but pretty expensive.

Mike
--
D. Michael Basinger:    Not speaking for I.U. or the School of HPER
Computer Specialist     dbasinge@bronze.ucs.indiana.edu
School of HPER          dbasinge@arapahoe.ucs.indiana.edu (NeXT Mail)
Indiana University      Phone: (812) 855-1562   Fax: (812) 855-4983

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 15:32:56 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   What is a FIX network?

A friend has a map of the Australian Internet that talks about a connection
to FIXwest. I also have have a README about the multicast backbone that talks
about FIX ethernets.

What the heck is FIX?

Thanks,

Mark


-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 16:09:56 GMT
From:      markus@edfd.uucp (Markus Gruenkorn (MAGIC))
To:        comp.protocols.tcp-ip,de.comm.misc
Subject:   Connection of 2 terminals with serial ports over ethernet (TCP/IP) !


Hi guys !
I want to connect 2 async. terminals with a RS232 over a TCP/IP
ethernet. The terminals should think that there only is one serial
line between them. Any cheap solutions, any suggestions !
I would appreciate any information !
Thanks in advance !
-- 
------ < MAGIC > ------

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1992 16:34:41 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

In article <1fn5h5INNa03@sequoia.ccsd.uts.EDU.AU> M.Gream@uts.EDU.AU (Matthew Gream) writes:
>It seems that Urgent TCP data makes it easier for packet injection,
>since sequence number checking does not occur with the urgent part
>of the datagram.

Actually, (and now I'm going to show my ignorance again) that part of
Comer and Stevens always confused me.  Where in the standards does it
say that urgent data doesn't get sequence-number-checked?  Where does
it say that one should move data in urgent-flagged packets out of
sequence to the application?

I admit that I find urgent data to be quite murky, but from my reading
of RFC's 793 and 1122, it seems that urgent data is processed in sequence,
just like normal data.  Look especially at RFC 793, in the Functional
Specification, pages 69 and 73.  The description there checks the
sequence number, then the urgent field.  There is no mention of skipping
the sequence number check if the urgent bit is set.

Now someone tell me I'm wrong so I can go rip out and rewrite my code...  ;-)

-- 
Stephen Trier                                    It's either very surprising
Network Services Engineering, IRIS/INS/Telecom    or not surprising at all.
Case Western Reserve University                    Let me think about it.
trier@ins.cwru.edu                                       - Palmer Davis

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 16:40:23 GMT
From:      mike@ulinf0.unil.ch (Michael Bloch)
To:        comp.unix.questions,comp.unix.hp,comp.unix.msdos,comp.dcom.modems,comp.protocols.tcp-ip,comp.sys.hp
Subject:   SLIP connection at 9600 bauds (TELNET, X11)

I have a need to connect the two following systems :

HP 9000/710 running HP/UX
Ethernet connection to the Internet
Modem on a serial port

and

PC 386/20 running Windows 3 (could be 3.1)
VGA screen
Modem on a serial port

I want to run TCP/IP between the PC and the HP. This would mean SLIP.
The goal is to use TELNET, FTP and a mail program. If possible I would
like to run X11 on the PC.

Questions :
- is a SLIP connection at 9600 bauds fast enough to be usable (e.g. for TELNET)
- is a X11 connection over SLIP, at 9600 bauds usable ?
- which TCP/IP stack should I use (even commercial) ?
- which X11 implementation should I use ?

Have you done it ? Do you another technical solution ?

Thanks for your help
Best regards,

Michael

-- 
Michael Bloch, Research Assistant               Internet : mike@ulinf0.unil.ch
University of Lausanne, Switzerland		BIX ID   : astolfi

If I have seen farther, it is by standing on the shoulders of giants - I. Newton

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1992 16:49:32 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   What happened to fast retransmit?

What is the status of the fast retransmission and agressive ack policy
mentioned in Jacobson's "Congestion Avoidance and Control" and RFC 1122?
Is is widely implemented, or is it still experimental?  Are there any
published descriptions of the algorithms?

-- 
Stephen Trier                                    It's either very surprising
Network Services Engineering, IRIS/INS/Telecom    or not surprising at all.
Case Western Reserve University                    Let me think about it.
trier@ins.cwru.edu                                       - Palmer Davis

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 16:54:35 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   >Choosing port numbers for TCP servers

Port assignments for all Internet protocols are controlled by the
Internet assigned numbers authority (IANA), who is Jon Postel (postel@isi.edu).
If you want a port to really be yours, you have to register with Jon (and
he usually requires an RFC describing the protocol used on the port).

The latest Assigned Numbers RFC (RFC 1340), states that the well-known port
space is currently 0-1023.  Section 4.2.2.1 of RFC 1122 (Host Requirements)
also talks a bit about port policies.

The IANA is the only port assignment authority and all other
practices are merely local or operating system-specific conventions.

Craig

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 17:11:57 GMT
From:      seant@bluefish.ratsys.com (Sean D. True)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Help: Banyan VINES ARP problem w/ PC/TCP

Our local network configuration has a number of PC's accessing network
servers under Banyan VINES. We run the Banyan server version of PC/TCP from
FTP software.

On this network there are two non-PC devices: a Sun used as mail and news
server, and a Telebit Netblazer used as our bridge to the outside world.
We access both the Sun and the Netblazer from PC's via Banyan.

PC access (Telnet, whatever) to the Sun is solid and reliable. PC access
to the Netblazer is unreliable. Sun access to the Netblazer is also solid
and reliable. (I run a ping demon that pings our Internet host every five 
minutes). After some serious poking around, we determined that the TCP
router on Banyan was losing the ARP information for the Netblazer
(I actually watched the address come and go in a system status display). 
What is worse, hard wiring the ethernet address in the ARP database did
not help!

So far, this is just a bug. Now for the perplexing part (to me, at least).
We discovered that if we ping'ed the Netblazer from the Sun, the Banyan server
never dropped the address. Even though the Banyan server is not involved
in the transaction in any obvious way. Pinging *through* the Netblazer is
not enough -- a ping to it's own IP address is required.

Any comments?




-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 18:13:12 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

	Because the specification is so unclear, and no implementation that
I know of does urgent data processing fully and correctly beyond any doubt,
I can't say that the way I do it is absolutely correct in all cases. However,
as the book says, for lack of a clear standard, or a de facto standard, we
chose an interpretation and that's what we implemented.
	In this case, the reason the sections you quoted (pages 69 & 73) don't
necessarily apply is that, for all the "segment arrives" description, it says:

	"In the following it is assumed that the segment is the idealized
        segment that begins at RCV.NXT and does not exceed the window."

	Of course, you can't do that in a real implementation. The reason
we skip the window processing code for urgent data is this (RFC 793, page 25):

	"However, even when the receive window is zero, a TCP must process
		the RST and URG fields of all incoming segments."

	Arguably, processing it regardless of the sequence number is too much,
but putting ordinary window constraints on the segment is clearly too little.
We have extended "receive window being zero" to the segment not falling into
the receive window, since I doubt that the intent was that you should *not*
do urgent bit processing if, for example, the receive window were 1 and the
urgent data was 5 bytes beyond that.
	I think the "right" way to do urgent data processing in general, and
window processing on it in particular, is still very subjective and will stay
so until many of these points are clarified and someone has a working example.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 92 18:54:06 GMT
From:      kenneth@bnrmtl.bnr.ca (Ken Rosenfeld)
To:        comp.protocols.tcp-ip
Subject:   TLI: t_accept returns TLOOK (summary)

The t_accept function in the TLI library returns a TLOOK
error, with event T_LISTEN, if there is an outstanding
connect indication.  How should a server handle this? 
What did the designers of TLI have in mind?

Thanks for your responses.  Here is a summary:

(1) Bind the server with qlen = 1.  Then the TLOOK error
    will not occur.  However, clients may find the server
    busy and be forced to retry the connect.  A tempting
    solution (for servers) but not really appropriate.

(2) Store outstanding connect indications in an array.
    Examples of this solution are in Sun's Network Programming
    Guide and in the AT&T SVR3 manual.

(3) The extra code required by (2) is useful for servers who
    want to prioritize the acceptance of outstanding connect
    indications.  For others, it is an inconvenience.

Ken Rosenfeld
kenneth@bnr.ca


-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 19:05:54 GMT
From:      jessea@u013.me.vp.com (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Network traffic and overloading an interface.

I have a question about network traffic that the gurus out that may be
able to help me with.

We've got 6 10BaseT HP hubs here.  Let's say that we've got 5 servers
that are used heavily network-wise and we put all 5 servers on one hub.
Is this a problem network traffic wise?  Would it be better to put 1
server per hub instead of 5 on one hub and why?

-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 19:13:56 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

In article <1fn5h5INNa03@sequoia.ccsd.uts.EDU.AU> M.Gream@uts.EDU.AU (Matthew Gream) writes:
>It seems that Urgent TCP data makes it easier
>for packet injection, since sequence number checking does not occur
>with the urgent part of the datagram.

You are misinformed.  Urgent data is not accepted out of sequence,
although some old TCP/IP implementations, having received the urgent
data in its proper sequence, will *deliver* it to the TCP application
"out of band".

If the TCP implementation you're looking at is delivering out of
sequence urgent data to the application before the intervening TCP
data has arrived, you should immediately throw it in the nearest trash
can: it's not worth the disk space it's being stored in.  The urgent
data would have to be delivered to the application before it could be
acknowledged to the peer.  Delivering acknowledged data out of band
could be argued for, although i think it's now generally recognized to
be a bad idea.  Delivering unacknowledged data in any form is clearly
dead wrong.  In fact, it's so wrong i really must doubt that any TCP
implementation actually does it.  I'm hoping you just misunderstood
what you were looking at.

I don't think it's too hard to hijack a TCP connection, but i don't
think this is a way to do it.  Even if it did work, most modern
applications don't use out of band data anyway.
						don provan
						donp@novell.com

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1992 19:38:59 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

In article <ByqyM2.Ex1@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	"However, even when the receive window is zero, a TCP must process
>		the RST and URG fields of all incoming segments."

It is interesting how you interpret that.  I took it to mean that I must
process the RST and URG fields, not that I must accept data beyond the
receive window.  In other words, my TCP takes appropriate actions if the
RST bit is set, and I notify the application of urgent data if I see URG.
That does not mean my TCP accepts the data itself; it means only that it
handles the notification that urgent data is pending farther in the data
stream.

Out of curiosity, does your TCP send ACKs for urgent data beyond the
current receive window, or do you wait for normal data to arrive to flesh
in the gap between rcv.nxt and the urgent data?  This was the biggest
problem I thought I saw in out-of-sequence urgent data -- it would seem to
cause all sort of problems with acknowledgments.

Obviously, such labels as "right" and "wrong" are very hard to place in
view of so many differing interpretations of the RFCs, and I'm certainly
not the one placing them!  However, since we've had 11 years without
clarification in the official documents, some discussion of different
interpretations certainly doesn't hurt.

-- 
Stephen Trier                                    It's either very surprising
Network Services Engineering, IRIS/INS/Telecom    or not surprising at all.
Case Western Reserve University                    Let me think about it.
trier@ins.cwru.edu                                       - Palmer Davis

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 19:54:21 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Urgent Data Explained (was Re: TCP_URG, does it lower security?)

In article <1fo1b1INNcvd@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
>I admit that I find urgent data to be quite murky

Urgent handling *is* murky, as is demonstrated by the fact that there
are almost as many different ways of handling urgent data as there are
TCP implementations.  Here's the way i think of it, although i make no
claims that this is the way the inventors or any implementers view it:

The key is not thinking of "urgent" as being equivalent to "important".
Think of it more as you think of (pardon me) an urgent need to go to the
bathroom.  "Urgent data" isn't the *new* data, it's the data between the
current location in the stream and the new data: it's urgent not because
it's important, but because it's *unimportant*.  (Uh, i won't be rude,
but if you take my anology this far, there's a perfect, vulgar word that
should leap to mind to describe this data.)  It needs to be urgently
*disposed* of so the important data (which *follows* the urgent data)
can be processed.

As i say, i may be the only person on Earth that thinks of urgent data
this way, but in all my studying of the specs, this is a consistent
and useful interpretation.  RFC-793 has some sections that agree well
with this interpretation, although i must admit that it has some cases
where it agrees with the more common attitude of viewing the *new*
data as the "urgent data".  In my opinion, the sections taking this
common view tend to be the cause of the confusion.  The protocol
itself only has an urgent pointer.  If you read RFC-793 thinking that
the data *before* the urgent pointer is the unimportant "urgent data"
and the data pointed to by the urgent pointer is the important data,
everything seems to fall into place nicely.

Unfortunately, various TCP protocol implementations, application
protocols, and application implementations have differing views, so
this nice clean idea cannot be globally applied to the current state
of TCP/IP in the field.
						don provan
						donp@novell.com

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 20:24:22 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

	Since ACK's are cumulative and, in general, you won't have received
(non-urgent) data that falls in between what you have and the urgent data,
you can't ACK it until you've caught up, which is what my implementation does.
	I think your interpretation is interesting, but what does it mean to
"process" the urgent bit without the urgent data? The application can't go
into "urgent mode" like it's supposed to, because there is no urgent data
that is deliverable. And there can't be until the end of the window passes
over the urgent pointer. But that means you need to do non-urgent processing
until the urgent pointer falls in the window, which sounds like ignoring
the urgent bit on packets outside the window to me.

[response to Don Provan's comments]
	Re: passing non-acked data to the application; that happens in
virtually every TCP. At the time you deliver the data, you may send an
acknowledgement, but you have no information about whether the other side
received it. That is, you have committed the sin of delivering unacknowledged
data to the application. And so I guess we'd better just trash this whole
Internet thing. Sure, we tried, but it just doesn't work. :-)
	Or not.

	More seriously, even if it falls within the window, you aren't supposed
to sit on it until you fill in any gaps of data that may appear before the
urgent data. But you can't acknowledge the urgent data until you've received
everything up to it. So, again, whether it passes the window tests or not, and
even if you don't lose ACK's to the other side, you have to pass unacknowledged
data to the application. I don't see what the problem is; you'll ACK it when
you get that far, and if you abort before then, the other side in any case will
never have information about how much you actually received. A lower bound,
maybe, but you could have received and processed more.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 20:33:41 GMT
From:      jessea@u013.me.vp.com (Jesse W. Asher)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   CSU/DSU that will accept V.25bis dialing commands?

Anyone know of any CSU/DSUs that will accept V.25bis dialing commands?
We'd like to use switched digital lines between our locations, but our
routers (Telebit Netblazers) will only use V.25bis for dialing.  Anyone
know of such an animal?

-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 20:40:06 GMT
From:      logica@lascar.puc.cl (Claudio Lopez)
To:        comp.protocols.tcp-ip
Subject:   writing program for a packet driver

	We need to write a program to get and analyze packets coming out 
from a packet driver. We think there should be some specs that tell you
how to interact with such a driver. We are trying to write a small tcp 
analyzer.

	Can someone tell me where to look for ?

        Claudio Lopez
	logica@lascar.puc.cl
	

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 21:16:03 GMT
From:      vickroy@turtle.cis.ohio-state.edu (james michael vickroy)
To:        comp.protocols.tcp-ip
Subject:   Re: 3270 emulator under Unix? [long]

Jerzy Pawlus (yppawlus@cyf-kr.edu.pl) wrote:
: Hi,
: 
:   Does anybody know the ftp location where I can find Emulator of IBM 3270
: terminal running under Unix (preferably SunOS 4.1.1)
: 
: Jerzy Pawlus                      ACK CYFRONET, Krakow, Poland
: Internet: yppawlus@cyf-kr.edu.pl

Here's the archie output.  I recommend x3270...I run it under OW3.

Host agate.berkeley.edu

    Location: /pub/386BSD/386bsd-0.1/filesystem/usr/bin
           FILE -rwxr-xr-x     196608  Jul 13 06:34  tn3270
    Location: /pub/386BSD/386bsd-0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxr-xr-x        512  Jul 18 01:29  tn3270

Host alw.nih.gov

    Location: /pub/brunetti/Mac
      DIRECTORY drwxrwxrwx        512  Nov  7 1991  tn3270
    Location: /pub/brunetti/PC
      DIRECTORY drwxrwxrwx        512  Nov  7 1991  tn3270

Host archive.cis.ohio-state.edu

    Location: /pub
      DIRECTORY drwxrwxr-x        512  Jun 19 1991  tn3270

Host ascwide.ascii.co.jp

    Location: /pub/NET/bsd-network
      DIRECTORY drwxr-xr-x       2048  Nov  2 1991  tn3270
    Location: /pub/NET/bsd-network/tn3270
      DIRECTORY drwxr-xr-x       2048  Nov  2 1991  tn3270

Host athene.uni-paderborn.de

    Location: /uninstalled/4.3-net2/usr.bin
      DIRECTORY drwxr-xr-x        512  Jul  9 09:48  tn3270

Host brolga.cc.uq.oz.au

    Location: /pub/NCSA_Telnet
      DIRECTORY drwxr-xr-x        512  Sep  8 1988  tn3270

Host climate.gsfc.nasa.gov

    Location: /pub
      DIRECTORY drwxr-xr-x        512  Oct 26 13:49  tn3270

Host cs.ubc.ca

    Location: /mirror1/bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  May 28 12:25  tn3270
    Location: /mirror3/386BSD/386bsd-0.1/filesystem/usr/bin
           FILE -rw-r--r--     196608  Jul 12 23:34  tn3270
    Location: /mirror3/386BSD/386bsd-0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxr-xr-x        512  Aug  5 20:49  tn3270

Host csc2.anu.edu.au

    Location: /pub/NCSA/Mac/Telnet/contributions
      DIRECTORY drwxr-xr-x       1024  Oct  4 14:16  tn3270

Host eceserv0.ece.wisc.edu

    Location: /pub
      DIRECTORY drwxr-xr-x        512  Sep 16 20:26  tn3270
    Location: /pub/tn3270
           FILE -rwxr-xr-x     352256  Oct 10 1991  tn3270

Host ee.utah.edu

    Location: /Comm
      DIRECTORY drwxr-xr-x       1024  Jun 19 02:07  tn3270
    Location: /admin
      DIRECTORY drwxr-xr-x       1024  Apr 12 1991  tn3270
    Location: /bin
           FILE -rwxr-xr-x     493409  Sep  8 1989  tn3270

Host emx.cc.utexas.edu

    Location: /pub/mnt/source/tcp-ip/tn3270-4.1.1
      DIRECTORY drwxr-xr-x        512  Nov  8 1990  tn3270

Host f.ms.uky.edu

    Location: /pub2/386bsd-0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxrwxr-x        512  Nov 25 08:04  tn3270

Host files1zrz.zrz.tu-berlin.de

    Location: /pub/net
      DIRECTORY drwxrwxr-x       1024  Oct 10 1991  tn3270

Host ftp.denet.dk

    Location: /mirror1/bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  Oct 18 22:48  tn3270

Host ftp.uni-kl.de

    Location: /pub/tcp.ip/NCSA_Telnet
      DIRECTORY drwxrwxr-x        512  Nov 15 1990  tn3270
    Location: /pub2/packages/bsd-sources/usr.bin
      DIRECTORY drwxrwxr-x        512  Apr 17 1992  tn3270

Host ftp.uu.net

    Location: /networking/applic/NCSA_Telnet
      DIRECTORY drwxr-xr-x       1024  Jul 29 15:01  tn3270
    Location: /networking/applic/NCSA_Telnet/tn3270
      DIRECTORY drwxr-xr-x        512  Jun  3 00:00  tn3270
    Location: /systems/unix/bsd-sources/usr.bin
      DIRECTORY dr-xr-xr-x        512  Jul 29 16:08  tn3270

Host gatekeeper.dec.com

    Location: /.0/BSD/net2/usr.bin
      DIRECTORY dr-xr-xr-x        512  Oct 31 18:35  tn3270
    Location: /.3/net/ip/applic/NCSA
      DIRECTORY dr-xr-xr-x       1024  Oct 31 18:28  tn3270

Host goya.dit.upm.es

    Location: /info/msdos/network
      DIRECTORY drwxrwxr-x        512  Jun 20 1991  tn3270

Host imag.imag.fr

    Location: /archive/macintosh/telnet-ncsa
      DIRECTORY drwxr-xr-x       1024  Nov 15 1991  tn3270

Host iraun1.ira.uka.de

    Location: /systems/unix
      DIRECTORY drwxrwxr-x        512  Oct 17 1990  tn3270

Host isfs.kuis.kyoto-u.ac.jp

    Location: /BSD/386bsd-0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxrwxr-x        384  Aug  8 15:48  tn3270

Host jhunix.hcf.jhu.edu

    Location: /pub/bsd-sources/usr.bin
      DIRECTORY dr-xr-xr-x        512  Sep  8 11:55  tn3270

Host lth.se

    Location: /archive2/netnews/sys.sun/volume89/apr
           FILE -r--r--r--        531  Nov 18 1989  tn3270
    Location: /archive2/netnews/sys.sun/volume89/jul
           FILE -r--r--r--        519  Nov 18 1989  tn3270

Host mailer.cc.fsu.edu

    Location: /pub/mac
      DIRECTORY drwxr-xr-x        512  Sep 30 15:08  tn3270

Host metro.ucc.su.oz.au

    Location: /pub/NCSA_Telnet
      DIRECTORY drwxr-xr-x       1024  May  6 00:00  tn3270

Host munnari.oz.au

    Location: /bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  Sep 26 22:06  tn3270

Host nic.switch.ch

    Location: /software/mac/telnet
      DIRECTORY drwxrwxr-x        512  Jun 18 1991  tn3270

Host nic.wisc.edu

    Location: /wiscnet/userguide
           FILE -rw-r--r--       3874  Nov  8 1991  tn3270

Host nisc.jvnc.net

    Location: /pub/MAC
      DIRECTORY drwxrwxr-x        512  May 10 1991  tn3270

Host nz20.rz.uni-karlsruhe.de

    Location: /pub/hp-ux
      DIRECTORY dr-xr-xr-x       1024  Apr 20 1992  tn3270

Host orion.oac.uci.edu

    Location: /ntslib/mac
      DIRECTORY drwxr-xr-x        512  Nov 22 1991  tn3270

Host procyon.cis.ksu.edu

    Location: /pub/386BSD/386bsd-0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxr-xr-x        512  Jul 25 03:25  tn3270

Host relay.iunet.it

    Location: /unix/4.3BSD/4.3bsd-net2/usr.bin
      DIRECTORY drwxrwxr-x        512  Mar 31 1992  tn3270

Host risc.ua.edu

    Location: /pub
      DIRECTORY drwxr-xr-x        512  Jun 14 1991  tn3270

Host rs3.hrz.th-darmstadt.de

    Location: /pub/os/bsd-net2/usr.bin
      DIRECTORY drwxr-xr-x        512  Jan 14 1992  tn3270

Host saqqara.cis.ohio-state.edu

    Location: /
      DIRECTORY drwxrwxr-x        512  Jun 19 1991  tn3270

Host serv1.cl.msu.edu

    Location: /pub/unix/SunOS
      DIRECTORY drwxr-xr-x        512  Apr 17 1992  tn3270

Host src.doc.ic.ac.uk

    Location: /computing/operating-systems/unix/386bsd-public/386bsd-0.1/filesystem/usr/bin
           FILE -r--r--r--     196608  Jul 13 07:34  tn3270
    Location: /computing/operating-systems/unix/386bsd-public/386bsd-0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxr-xr-x        512  Jul 19 02:55  tn3270
    Location: /computing/operating-systems/unix/4.3bsd-reno/usr.bin
      DIRECTORY drwxr-xr-x        512  Nov  5 1991  tn3270
    Location: /computing/operating-systems/unix/bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  Jan  6 1992  tn3270
    Location: /usenet/comp.archives/internet
      DIRECTORY drwxr-xr-x        512  May  3 1991  tn3270
    Location: /usenet/comp.archives
      DIRECTORY drwxr-xr-x        512  May  2 1991  tn3270

Host sun0.urz.uni-heidelberg.de

    Location: /pub/386BSD/386bsd-0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxr-xr-x        512  Nov 20 18:31  tn3270
    Location: /pub/NCSA_Telnet
      DIRECTORY drwxr-xr-x       1024  Nov 20 18:13  tn3270
    Location: /pub/NCSA_Telnet/tn3270
      DIRECTORY drwxr-xr-x        512  Nov 20 18:13  tn3270
    Location: /pub/bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  Nov 20 18:05  tn3270

Host sune.stacken.kth.se

    Location: /disk2/OS/bsd-net2/usr.bin
      DIRECTORY drwxr-xr-x        512  Sep 13 20:15  tn3270

Host sunic.sunet.se

    Location: /gopher-data/bin
           FILE -rwxr-xr-x     180224  Jul 31 11:41  tn3270

Host sunsite.unc.edu

    Location: /pub/packages/terminal-emulators
      DIRECTORY drwxr-xr-x        512  Apr 21 1992  tn3270

Host svin02.info.win.tue.nl

    Location: /pub/bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  Jan 20 1992  tn3270

Host theory.tc.cornell.edu

    Location: /pub
      DIRECTORY drwxr-xr-x        512  Jun 15 1990  tn3270

Host toklab.ics.osaka-u.ac.jp

    Location: /UUNET91/vol2/NCSA_Telnet
      DIRECTORY drwxr-xr-x        512  May  4 1991  tn3270
    Location: /UUNET91/vol9/bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  May  4 1991  tn3270

Host ucbvax.berkeley.edu

    Location: /pub
      DIRECTORY drwxr-xr-x        512  Mar 20 1991  tn3270

Host ugle.unit.no

    Location: /pub/unix/386bsd/des
           FILE -rw-r--r--     200704  Aug 12 17:09  tn3270
    Location: /pub/unix/bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  Feb 16 1991  tn3270

Host unibi.hrz.uni-bielefeld.de

    Location: /soft/unix
      DIRECTORY drwxr-xr-x       1024  Feb 12 1991  tn3270

Host unix.hensa.ac.uk

    Location: /pub/uunet/networking/applic/NCSA_Telnet
      DIRECTORY drwxrwxr-x       1024  Aug  1 08:24  tn3270
    Location: /pub/uunet/networking/applic/NCSA_Telnet/tn3270
      DIRECTORY drwxr-xr-x        512  Dec 22 1991  tn3270
    Location: /pub/uunet/systems/unix/bsd-sources/usr.bin
      DIRECTORY drwxr-xr-x        512  Aug  1 13:57  tn3270

Host uvaarpa.virginia.edu

    Location: /pub/sun/sun3
      DIRECTORY drwxr-xr-x        512  Aug  7 1991  tn3270
    Location: /pub/sun/sun3/tn3270
           FILE -rw-r--r--     139264  Aug 28 1990  tn3270
    Location: /pub/sun/sun4/sunos-4.1.2
           FILE -rw-r--r--     172032  Oct 19 23:33  tn3270
    Location: /pub/sun
      DIRECTORY drwxr-xr-x        512  Aug  7 1991  tn3270
    Location: /pub/sun/tn3270
           FILE -r--r--r--     155648  Jul  1 1988  tn3270

Host wasp.eng.ufl.edu

    Location: /
           FILE -rwxr-xr-x     233472  Sep 26 1991  tn3270

Host wnoc-fuk.wide.ad.jp

    Location: /pub/386BSD/386BSD0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxrwxr-x        512  Sep  3 23:21  tn3270

Host wuarchive.wustl.edu

    Location: /mirrors2/4.3bsd-reno/usr.bin
      DIRECTORY drwxr-xr-x        512  Jun  9 21:00  tn3270
    Location: /mirrors4/386bsd/386bsd-0.1/filesystem/usr/bin
           FILE -r--r--r--     196608  Jul 13 01:34  tn3270
    Location: /mirrors4/386bsd/386bsd-0.1/filesystem/usr/src/usr.bin
      DIRECTORY drwxr-xr-x        512  Aug  2 12:32  tn3270

Host zaphod.ncsa.uiuc.edu

    Location: /Mac/Telnet/contributions
      DIRECTORY drwxr-xr-x       1024  Apr 21 1992  tn3270







Host cs.dal.ca

    Location: /pub/comp.archives
      DIRECTORY drwxrwxrwx        512  Mar 14 1991  x3270

Host dsrbg2.informatik.tu-muenchen.de

    Location: /public2/X11/contrib/clients
      DIRECTORY drwxrwxr-x        512  Aug 22 1991  x3270

Host erratic.bradley.edu

    Location: /gnu-cdrom/contrib/x32701_2
      DIRECTORY dr-xr-xr-x        400  Nov 19 1991  x3270

Host kappa.rice.edu

    Location: /X11R4/bin
           FILE -rwxr-xr-x      40964  Feb 16 1991  x3270

Host nic.switch.ch

    Location: /software/sources/X
      DIRECTORY drwxrwxr-x        512  Jul 24 07:00  x3270

Host reseq.regent.e-technik.tu-muenchen.de

    Location: /informatik.public2/X11/contrib/clients
      DIRECTORY drwxrwxr-x        512  Aug 22 1991  x3270

Host src.doc.ic.ac.uk

    Location: /usenet/comp.archives/internet/tn3270
      DIRECTORY drwxr-xr-x        512  May  3 1991  x3270
    Location: /usenet/comp.archives/x11
      DIRECTORY drwxr-xr-x        512  Jun 15 1991  x3270

Host urec.urec.fr

    Location: /pub/renater/sna
           FILE -rw-r--r--        237  Nov  9 10:50  x3270


-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 21:31:41 GMT
From:      vickroy@skink.cis.ohio-state.edu (james michael vickroy)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP API Recommendations?

I'm looking for a commercial implementation of a internet protocol
suite API that has both a sockets and TLI interface.  The eventual
platforms (at least right now) are Sun and IBM (3090 and RS/6000).

Any recommendations would be appreciated.

thanks,
jim
--
Jim Vickroy, ____                         | Voice:        +1 614 764 4343
Reference Services/Database Development   | FAX:          +1 614 764 2344
OCLC Online Computer Library Center, Inc. | Internet:    vickroy@oclc.org
6565 Frantz Road, Dublin Ohio, 43017-0702 | uucp:     osu-cis!fssun09!jmv


-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 21:59:02 GMT
From:      matt@wardsgi.med.yale.edu (Matt Healy)
To:        comp.protocols.tcp-ip
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

In article <369@snll-arpagw.llnl.gov>, hwstock@snll-arpagw.llnl.gov
(stockman harlan w) wrote:
> 
> >> P.S. How would you rate 500KB/sec?
> >
> >
> >That depends on the medium.
 [...]
> >
> >P.S.  Over ethernet 500KB/s would be poor for a modern workstation, but
> >    common for a PC.  As measured by `ttcp`.  Ftp ttcp source from
> >    brl.mil or sgi.com
> 
> It may be possible to get >> 500 kB/sec in a "modern" network, with a
> moderate amount of traffic and direct connections, but in many older
> buildings retrofitted for ethernet, it is hard to be guaranteed > 100
> kB/sec. I'm hooked up through a tranceiver in a building with about 200
> users. I've monitored PC-workstation, workstation workstation, etc
> transfer rates, and find we rarely get above 100 kB/sec on a busy day.
> Many people leave long postscript print jobs for the wee hours, so it is
> hard to find any optimum time. Rates between two SGI workstations are no
> different than the rates (on average) between a workstation and a PC
> with an 8-bit, 8 MHz wd8003 card. That's life.

Late at night (when the Ethernet is not very busy) I have done
some experiments with Silicon Graphics workstations.  The best
I have ever managed is 404 Kilobytes per second with packets just
over 2000 bytes.  Smaller packets are slower because there is then
more overhead, and for some reason throughput on my net drops
drastically when packet size hits 2kBytes.  Crunching some numbers
indicates that is about 1/3 of Ethernet's theoretical bandwidth of
10 million bits per second.  I doubt the background activity on the
rest of the net made much difference-- just before and after I ran
this test I measured bandwidth utilization at 0.4 percent.  Can the
TCP/IP and Ethernet overhead eat up 2/3 of the bandwidth, or are my
SGIs the limiting factor?  Using the SGI at one end and a Mac Quadra
900 at the other managed about 80 percent of this result.

Matt Healy
"I pretend to be a network administrator;
 the lab net pretends to work"

matt@wardsgi.med.yale.edu

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 22:03:56 GMT
From:      rchen@fraser.sfu.ca (Robert Chen)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.os.linux
Subject:   WANTED: TINY FTP CLIENT

Hi.  I am looking for a "tiny ftp", using BSD type sockets.  Basically,
I am looking for some stripped down version that is just capable of
loggin in and receiving a binary file, and possibly reading a remote 
directory, but nothing else.  

I am sure many people have written such a program as a project in an
undergraduate networking class, but I am having trouble locating such 
a beast.

I have considered starting with the BSD sources and start hacking out
stuff, but it would be cleaner to start small.  I have also considered
writing something myself, but I know that would be re-inventing the
wheel.  The code would be used on a boot floppy disk for linux to 
allow network installation without taking up too much space.  It would
probably be controlled by another process, so UI is not even that important.

Please follow up to email and/or comp.sources.wanted.

- Ken

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 23:23:20 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

In article <Byr4oo.I0K@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	I think your interpretation is interesting, but what does it mean to
>"process" the urgent bit without the urgent data? The application can't go
>into "urgent mode" like it's supposed to, because there is no urgent data
>that is deliverable.

I'm sorry, but you're clearly laboring under the misconception that
the TCP specification calls for urgent data to be delivered out of
order.  The protocol itself calls for an urgent pointer to switch the
application into "urgent mode", which dictates how it processes the
data stream.  It does *not* alter the order of the data in the data
stream at all.  Delivering the new data "out of band" was strictly an
implementation "innovation" created by BSD4.2, one of the many such
"innovations" that have cursed TCP/IP ever since.

Since the urgent field does not necessarily point to any data in the
current packet, it's fairly clear, i think, that "processing" the
urgent field can't have anything to do with the data the urgent field
points to.

>And there can't be until the end of the window passes
>over the urgent pointer.

I agree that the location of the end of the window has nothing to do
with it.  It's *never* correct to deliver out of sequence data, no
matter where the window is.

>	Re: passing non-acked data to the application; that happens in
>virtually every TCP. At the time you deliver the data, you may send an
>acknowledgement, but you have no information about whether the other side
>received it.

I merely said it was wrong to deliver it before it was acknowledged:
it doesn't matter if the sender knows it was acknowledged.  But i must
admit, what i really meant was "before TCP knows it will ever be able
to acknowledge that data", since TCP might delay acknowledging the
data for a variety of reasons even though it has delivered it.  The
difference is that when delivering out of sequence data, TCP can't
guarantee that it will *ever* be able to acknowledge the data.

						don provan
						donp@novell.com

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4 Dec 1992 23:25:54 GMT
From:      omar@osf.org (Mark Marino)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,bit.listserv.ibmtcp-l
Subject:   PING for NCSA Telnet package.


  Hi,

  Does anyone know where I can find a "PING" command that works with the NCSA
Telnet package for IBM PCs?  Actually, any other TCP/IP commands that work
with the NCSA package would be great.

  If not for the NCSA package, how about any other implementations of TCP/IP
commands that work over an ethernet card on an IBM PC?

  Please send e-mail to: omar@osf.org, and I will summarize and post the
results.

Thanks,
Mark


-- 
 ----------------------------------------------------------------------------- 
|                                                                             |
| Mark Marino              | omar@osf.org           |  uunet!osf!omar         |
| Open Software Foundation | 11 Cambridge Center    |  Cambridge, MA 02142    |
|_____________________________________________________________________________|

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 92 23:35:00 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip,comp.benchmarks
Subject:   TCP/IP performance on 68040?

Does anybody have any information about what data rates are obtainable
over TCP/IP between two 68040-based machines?

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Dec 1992 00:21:12 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

In article <matt-041292164721@wardmac9.med.yale.edu>, matt@wardsgi.med.yale.edu (Matt Healy) writes:
> In article <369@snll-arpagw.llnl.gov>, hwstock@snll-arpagw.llnl.gov
> (stockman harlan w) wrote:
> > 
> > >> P.S. How would you rate 500KB/sec?
> > >
> > >That depends on the medium.
 [...]
> > >
> > >P.S.  Over ethernet 500KB/s would be poor for a modern workstation, but
> > >    common for a PC.  As measured by `ttcp`.  Ftp ttcp source from
> > >    brl.mil or sgi.com
> > 
> > It may be possible to get >> 500 kB/sec in a "modern" network, with a
> > moderate amount of traffic and direct connections, but in many older
> > buildings retrofitted for ethernet, it is hard to be guaranteed > 100
> > kB/sec. I'm hooked up through a tranceiver in a building with about 200
> > users. I've monitored PC-workstation, workstation workstation, etc
> > transfer rates, and find we rarely get above 100 kB/sec on a busy day.
> > Many people leave long postscript print jobs for the wee hours, so it is
> > hard to find any optimum time. Rates between two SGI workstations are no
> > different than the rates (on average) between a workstation and a PC
> > with an 8-bit, 8 MHz wd8003 card. That's life.
> 
> Late at night (when the Ethernet is not very busy) I have done
> some experiments with Silicon Graphics workstations.  The best
> I have ever managed is 404 Kilobytes per second with packets just
> over 2000 bytes.  Smaller packets are slower because there is then
> more overhead, and for some reason throughput on my net drops
> drastically when packet size hits 2kBytes.  Crunching some numbers
> indicates that is about 1/3 of Ethernet's theoretical bandwidth of
> 10 million bits per second.  I doubt the background activity on the
> rest of the net made much difference-- just before and after I ran
> this test I measured bandwidth utilization at 0.4 percent.  Can the
> TCP/IP and Ethernet overhead eat up 2/3 of the bandwidth, or are my
> SGIs the limiting factor?  Using the SGI at one end and a Mac Quadra
> 900 at the other managed about 80 percent of this result.


Excuse me, but I take this statement very seriously.

What benchmark are you using?  Which models of IRIS's?

Is there any chance that your benchmark is not quite right?
How do you control the packet size with TCP?  
How do you manage a 2000 byte packet over ethernet?  None of the ethernet
drivers should allow that.

Silicon Graphics has not shipped a system for years that a pair (while
operating correctly) would produce numbers less than 800KByte/sec from
`ttcp` (on a quiet ethernet, of course).  (There have been bugs
in some machines that have been fixed that have hurt performance.)
(Because of practice, I can type `ttcp -s -r -l32768` and `ttcp -t -s
-l32768 ohost` as quickly as many short words.)

If your machines, 4D/25's, 4D/200's, 4D/300's, 4D/400's, 4D/500's,
Indigos and newer machines, do not perform that fast with a reasonable
benchmark, no other jobs active, and a quiet ethernet, then please call
for service and/or check your ethernet for late collisions and similar
installation problems.



Vernon Schryver,  vjs@sgi.com

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sat, 05 Dec 92 02:19:44 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   writing program for a packet driver

In article <logica.7.0@lascar.puc.cl> logica@lascar.puc.cl writes:

           We need to write a program to get and analyze packets coming out 
   from a packet driver. We think there should be some specs that tell you
   how to interact with such a driver. We are trying to write a small tcp 
   analyzer.

Certainly, Claudio.  It's packet_d.109, which is in the Crynwr Packet
Driver Collection, and also:

	vax.ftp.com:pub/packet-d.ascii
	vax.ftp.com:pub/packet-d.mss

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

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Dec 1992 02:33:06 GMT
From:      rypma@waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

Matt Healy (matt@wardsgi.med.yale.edu) wrote:
: 
: Late at night (when the Ethernet is not very busy) I have done
: some experiments with Silicon Graphics workstations.  The best
: I have ever managed is 404 Kilobytes per second with packets just
: over 2000 bytes.  Smaller packets are slower because there is then
: more overhead, and for some reason throughput on my net drops
: drastically when packet size hits 2kBytes.

Running from an HP 700 series workstation to an HP X terminal, we've
measured close to (sometimes a little over, sometimes a little under)
1 MByte/s with not much else on the network. I rather doubt that an SGI
machine would be slower than a lowly X terminal :-)

Ted Rypma
HP Panacom Division

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Dec 1992 02:56:56 GMT
From:      fred@maccs.mcmaster.ca (Fred Whiteside)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: BOOTP ROM problem

In <1992Nov30.015027.419@coulomb.pcc.oz.au>, parson@coulomb.pcc.oz.au writes:
>In <3757@isgtec.isgtec.com> Bruce M. Walker (bmw@isgtec.com) wrote:
>: Beame & Whiteside's BOOTP ignores "directed" BOOTP replies, they have to
>: be broadcast to be recognized.  This drove me crazy until I accidentally
>: discovered that fact with an HP implementation of bootpd that has a flag
>: to do broadcasting instead of the more standard directed reply.

	We have (finally) identified this as being a problem in our
customisation program.  The TCP code will only recognise requests if they
are to our IP address or broadcasts or *if our IP is 0*.  The customisation
program fails to set the IP to zero when it sets the address mechanism to
BOOTP (or RARP, actually).  The (trivial) fix will be implemented in the
very near future ... the work-around is to customise your driver to have
an IP address of 0.0.0.0 and the re-customising it to use BOOTP to get its
address.  Sorry for the troubles, all.
 
>Is this also a problem with the FTP PC/TCP's bootpd?  It seems that
>the bootp requests are being broadcast instead of directed.

	I don't know if this is their behaviour, but it isn't a problem
with the bootpd at all, but in our bootp client side.

Fred Whiteside
Fred Whiteside   Beame & Whiteside Software Ltd., Caledonia, Ontario
fred@bws.com   fred@maccs.DCSS.McMaster.CA   ...!uunet!utai!utgpu!maccs!fred

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 92 06:06:59 GMT
From:      martillo@stars.clearpoint.com (Joachim Martillo)
To:        comp.protocols.snmp,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Document Available

The document, "Routing in a Bridged Network," is now available in
hsdndev.harvard.edu:/pub/ndtl/doc/{rtebridg.ps,rtebridg.ps.Z} via
anonymous ftp.

This document presents a consistent approach to internetworking design
using routers, bridges and hybrid bridge routers.  This document has
some relevance to some of the issues which have been discussed in the
comp.protocols.tcp-ip, comp.protocols.snmp and comp.protocols.ppp
newsgroups.

The document is encoded in postscript.  With some postscript printers
it may be necessary to reset the printer before or after printing the
document.

Joachim Carlo Santos Martillo Ajami
--
Joachim Carlo Santos Martillo Ajami

The article represents noone's opinions other than the author's.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Dec 1992 22:52:24 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

In article <1992Dec4.232320.3148@novell.com>, donp@novell.com (don provan) writes:
> I'm sorry, but you're clearly laboring under the misconception that
> the TCP specification calls for urgent data to be delivered out of
> order.  The protocol itself calls for an urgent pointer to switch the
> application into "urgent mode", which dictates how it processes the
> data stream.  It does *not* alter the order of the data in the data
> stream at all.  Delivering the new data "out of band" was strictly an
> implementation "innovation" created by BSD4.2, one of the many such
> "innovations" that have cursed TCP/IP ever since.

	It is not a "misconception;" it is an interpretation. RFC 793 does
not at all specify that urgent data should be delivered in order, *or* out
of order. "In order" is your interpretation, which doesn't make others (eg,
Berkeley's) "wrong."
	From RFC 793:

[Page 12]                                                               
  "TCP does not attempt to define what the user specifically does upon
	being notified of pending urgent data, but the general notion is
	that the receiving process will take action to process the urgent
	data quickly."

	Although it may be reading more than the authors intended into the
line, note it says "...*urgent* data quickly" (italics mine), and not just
that it should process *all* pending data quickly, or that all pending data
is part of the urgent data. All of these things are left undefined, and one
reasonable interpretation is that the data in the packet that contains the
urgent pointer, up through the urgent pointer, is the "urgent data" and that
TCP can deliver it promptly and independent of any other buffered data (that
is, out of order).
	I agree that your interpretation is also consistent with RFC 793,
though perhaps I'm more conservative in that I wouldn't go so far as to call
your interpretation either a "misconception" or grounds for throwing an
implementation using it into the trash. Neither is "right" or "wrong;" they
are simply different, because the wording in RFC 793 is not clear.
	But the fact is that all existing implementations that I know of
do it this way. Granted, that probably has more to do with Berkeley's choice
than an independent reading of the RFC, but if you want to talk to BSD-derived
machines, you either force the application to read and buffer all intervening
data itself, or you deliver the urgent data out of order. It's that simple.
	I agree completely that treating it as "out of band" data is ugly--
I tore my hair out implementing it that way-- but doing it the way that you
suggest is, frankly, not as useful in real programs, because it is definitely
*not* true that you can in general toss away the intervening data. And forcing
applications to buffer it and then process it later is uglier still.
Presumably, the program will already consume data as quickly as possible, so
an "urgent indication" that is only a prod in the side to hurry is of no use
at all. At least to any programs I've ever written. It's also more complicated
because it requires the higher-level protocol to mark the start of urgent data
separately.

	My personal opinion is that urgent data *should* be considered "out
of band" data, because that is more useful in applications, but that it
has no place in the ordinary sequence space and should have been handled
independently of it. What they really had in mind I don't know, but
considering all they did right, I can't fault them either for disagreeing
with me, or for not making that small part clear enough to be unambiguous;
whichever is the case. And whether Berkeley thought they were doing it right
or not, what they came up with is more handy to use.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 1992 02:37:48 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: What is a FIX network?

In article <1992Dec4.153256.23803@alias.com> mark@alias.com (Mark Andrews) writes:
}A friend has a map of the Australian Internet that talks about a connection
}to FIXwest. I also have have a README about the multicast backbone that talks
}about FIX ethernets.
}
}What the heck is FIX?
}
}Thanks,
}
}Mark
}

FIX stands for Federal Internet eXchange.  There are two sites in the
USA where all the federal IP backbones have their routers connected to a
common LAN.  This allows them to interchange packets with each other,
and with other major components of the Internet.  FIXwest is in
California and FIXeast is in Maryland.  There is also a CIX (Commercial
Internet eXchange).

    __   
   /  | /\                  Alex McKenzie
  /   | \/                  mckenzie@bbn.com
  \__/|_/\_&_/~X_           617/873-2962
 

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Dec 1992 03:45:41 GMT
From:      mat@phx.mcd.mot.com (Mat Cucuzella)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI: t_accept returns TLOOK (why?)

In article <1992Dec2.215556.25482@bnrmtl.bnr.ca> kenneth@bnr.ca (Ken Rosenfeld) writes:
>I'm writing a server using the TLI library for TCP
>(on a Sun).
>
>The server executes the following in a loop:
>
>  t_listen(listenfd, ...)        /* receive connect indication */
>    
>  t_accept(listenfd, newfd, ...) /* accept the call */
>
>There is a case where this code does not work: Two clients
>make connect requests before the server executes the t_listen().
>The t_listen() then receives the first connect indication.
>The t_accept() fails, however, with t_errno = TLOOK.  
>A subsequent call to t_look() returns the T_LISTEN event.
>
>Apparently this is correct behaviour.  The man page states:

[ good description removed ]

Ahhh, welcome to the world of TLI. This is a problem I've run into
countless times in the past several years. Be very suspicious of
BSD socket applications ported to TLI. I believe some of the BSD
type utilities in USL's Release 4.x have this problem, including
TI-RPC (except our version of course :-).

>I've looked at the excellent UNIX Network Programming book.
>The code does not handle the case of a t_accept() returning
>a TLOOK error, with event T_LISTEN. On page 361:
>
>    if (t_accept(listenfd, newfd, callptr) < 0) {
>        if (t_errno == TLOOK) {
>            /*
>             * An asynchronous event has occurred.  We must have
>             * received a disconnect.  Go ahead and call t_rcvdis(),
>             * then close the new file descriptor that we opened
>             * above.
>             */
>
>            if (t_rcvdis(listenfd, (struct t_discon *) 0) < 0)
>                err_sys("t_rcvdis error");
>            if (t_close(newfd) < 0)
>                err_sys("t_close error");
>            return(-1); /* return error to caller */
>        }
>        err_sys("t_accept error");

All of the code I've seen that works looks more like this:
    poll(2) on t_open()/t_bind() file descriptors
    for all active endpoints (or filedescriptors)
    do
	while tp = t_listen()
	do
	    queue tp on internal queue (link list)
	done
    done
    for all tp's on internal queue
    do
	/* may need to t_open new endpoint to accept on */
	t_accept(tp)
	if error
	    t_rcvdis()
	else
	    call server routine to handle new connection
	fi
    done

(I'm not sure if this is exactly right, but the flow should be close).

Alternately, in the t_bind() call you can set your "qlen" to
one, and assuming TCP honors this, your application should
never get two connection indications. However while you are
handling one, others could retransmit out and get connection
timeouts (not a very good workaround).

>What were the designers of TLI (and XTI) thinking of?

I'm not sure they were doing the T thing :-).

Hope this helps a little.

+--------------------------------++------------++------------------------+
| Mat Cucuzella                  || -K o o K-  || Remember,  if  you're  |
| {uunet|noao}!asuvax!mcdphx!mat ||     |      || not the lead dog, the  |
| mat@phx.mcd.mot.com            ||     -      || scenery never changes! |
+--------------------------------++------------++------------------------+

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Dec 1992 04:07:19 GMT
From:      mat@phx.mcd.mot.com (Mat Cucuzella)
To:        comp.unix.questions,comp.unix.hp,comp.unix.msdos,comp.dcom.modems,comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: SLIP connection at 9600 bauds (TELNET, X11)

In article <1992Dec4.164023.22527@ulci20.unil.ch> mike@ulinf0.unil.ch (Michael Bloch) writes:
>Questions :
>- is a SLIP connection at 9600 bauds fast enough to be usable (e.g. for TELNET)

I'm reading News on a 9600 bps SLIP connection from home now, and it
is very usable for telnet and ftp (see other response for CSLIP
and modems that compress data).

>- is a X11 connection over SLIP, at 9600 bauds usable ?

No. However there is a protocol(?)/application called Xremote made
especially for this purpose. I'm afraid I do not know much about it
but it does compression and other trickery to make serial lines usable.
See if it is available on the machines you have.

+--------------------------------++------------++------------------------+
| Mat Cucuzella                  || -K o o K-  || Remember,  if  you're  |
| {uunet|noao}!asuvax!mcdphx!mat ||     |      || not the lead dog, the  |
| mat@phx.mcd.mot.com            ||     -      || scenery never changes! |
+--------------------------------++------------++------------------------+

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 1992 17:54:30 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

In article <Byt67D.AAo@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	It is not a "misconception;" it is an interpretation. RFC 793 does
>not at all specify that urgent data should be delivered in order, *or* out
>of order. "In order" is your interpretation, which doesn't make others (eg,
>Berkeley's) "wrong."

Well, I do reserve the right call something wrong if I think it is.  Trivial
example: I'm going to build a TCP that never sets the PSH bit because I don't
think RFC-793 requires it.  That _is_ wrong, regardless of whether I think
my interpretation justifies it.

From my perspective, there are two faults with your interpretation of Urgent
data: First, you do not draw a line between the user and the TCP, and second,
you attempt to read too much into the spec.

For example, you quoted the following from RFC 793:
>[Page 12]                                                               
>  "TCP does not attempt to define what the user specifically does upon
>	being notified of pending urgent data, but the general notion is
>	that the receiving process will take action to process the urgent
>	data quickly."

This talks about the receiving process and the "user", not the TCP.  Sure,
some sort of out-of-band user read function might be nice to simplify this,
and I have no complaints about providing such an API if you really want it.
However, that does NOT mean that you should accept or deliver data, urgent
or not, received out-of-sequence on the TCP connection.

I don't see how my version -- notifying the application of the urgent data,
and leaving it up to the app to decide what to do -- violates this.

Now, let me propose Occam's Razor as a useful tool in interpreting protocol
specs: "never needlessly multiply entities".  If an interpretation of a
spec requires too much reading between the lines, there is a good chance the
interpretation is wrong.  I think the fact that neither 793 nor 1122 defines
a *TCP* urgent mode means that one probably isn't needed.  (Note that 793
does mention an *application* urgent mode, which is different, application-
defined, and sorely needed if urgent data is meaningful to the app.)
Likewise, the TCP spec doesn't say that urgent data must be accepted past
the window, nor does it say that urgent data loses the sequencing and check-
summing protections of normal data.  Your book comments that the spec doesn't
say how to determine how long "urgent data" is, so you pick an arbitrary
convention.  Reading all of these things into the spec is adding
complication that just isn't there, or "needlessly multiplying entities",
as Occam would say.

Please understand that when I first heard about urgent data, I saw it as
you do.  After trying to implement it, I came about full circle.  Nothing
that convoluted could be part of TCP -- the rest of the protocol is too
clean for it, and if it really were that messy, _it would say so_.  This
interpretation requires building too much on top of the spec -- stuff that
just isn't mentioned in the spec itself.

The goal isn't to decide what one thinks urgent data should be like, and
then to read the spec in such a way to permit that implementation, but to
try to figure out what the spec really requires.  If you think you need a
pure out-of-band data mechanism (something I think we'd agree TCP urgent
data surely is not), define a protocol that gives you pure out-of-band
data.  Just don't call it TCP.

-- 
Stephen Trier                                    It's either very surprising
Network Services Engineering, IRIS/INS/Telecom    or not surprising at all.
Case Western Reserve University                    Let me think about it.
trier@ins.cwru.edu                                       - Palmer Davis

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Dec 1992 18:08:00 GMT
From:      rich@Rice.edu (Richard Murphey)
To:        comp.unix.questions,comp.unix.hp,comp.unix.msdos,comp.dcom.modems,comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: SLIP connection at 9600 bauds (TELNET, X11)

In article <1992Dec6.040719.7838@phx.mcd.mot.com> mat@phx.mcd.mot.com (Mat Cucuzella) writes:
   In article <1992Dec4.164023.22527@ulci20.unil.ch> mike@ulinf0.unil.ch (Michael Bloch) writes:
   >- is a X11 connection over SLIP, at 9600 bauds usable ?

   No. However there is a protocol(?)/application called Xremote made
   especially for this purpose. I'm afraid I do not know much about it
   but it does compression and other trickery to make serial lines usable.
   See if it is available on the machines you have.

Rumor has it that Low Bandwdth X may be introduced in X11R6.  I
haven't actually used it.  Has anyone else here used the commercial X
terminals featuring this?  Rich

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 1992 18:42:22 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Urgent Data Explained (was Re: TCP_URG, does it lower security?)

Well, if I may pitch in how I see urgent data, I'd define it as a sort
of "super-push".  It gives the sending side a way to say, "I've got
something important for you N bytes ahead."  Just as push doesn't say
_what_ part of the current packet is important, urgent doesn't say what
part of that data N bytes ahead is important.

Since there is no way to know exactly what data is urgent, I leave the
precise definition of "urgent data", its length, and its relation to the
urgent pointer up to the application.  All the sending TCP knows is that
the application told it to mark some point in the data stream as "urgent",
and all the receiver knows is that it should tell the application that
the same point is "urgent".

There is nothing that says that setting the urgent bit suspends normal
TCP reliability guarantees.  Therefore, urgent data is sent and received
"on the wire" in sequence and within the window, just like any other data.

The TCP API, on the other hand, does not have to provide urgent data
strictly in sequence.  The API is free to provide whatever functions it
chooses -- I would think functions like "flush output buffer", "expand
receive window to accomodate urgent data", "peek ahead at urgent data",
and "discard input buffer up to urgent pointer" would be useful.  With
these or equivalent functionality, the application is not forced to read
and discard data itself; it's free to do anything it likes with the
information.

These functions are definitely not mandatory.  All that is required is
that the TCP can signal the application of the presence of urgent data
further down the data stream, preferably with an indication of how far
down the stream it is.  It is then up to the application to get at the
urgent data.  The exact API used is irrelevant, and the API used does
not change the way urgent data is exchanged between TCPs.

This "super-push" rule-of-thumb seems to work well in practice.  It fits
the use of urgent data in existing protocols, it guarantees reliable
delivery of both normal and urgent data, and it is simple.  The exact
API provided is irrelevant.

I find it interesting that while Don Provan uses different words to
describe the functioning of urgent, we end up with basically the same
definition.

-- 
Stephen Trier                                    It's either very surprising
Network Services Engineering, IRIS/INS/Telecom    or not surprising at all.
Case Western Reserve University                    Let me think about it.
trier@ins.cwru.edu                                       - Palmer Davis

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 92 20:48:34 GMT
From:      tbooth@wellfleet.com (Todd Booth)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.cell-relay
Subject:   CFV: comp.dcom.sys.wellfleet

Call For Votes

Proposed Newsgroup: comp.dcom.sys.wellfleet

Type: Unmoderated

Rationale: (discussed in RFD)

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

Voting Period: 
	From: the time this article is posted/circulated
	To:   midnight GMT, Tuesday, January 5th, 1993

How to Vote:
	To vote on comp.dcom.sys.wellfleet, send your vote to
		tbooth@wellfleet.com or tbooth@netcom.com

	You must specify your vote as one of the following:

		I vote "yes" on comp.dcom.sys.wellfleet
		I vote "no"  on comp.dcom.sys.wellfleet

Voting Rules:
	One vote per person. If you vote more than once, only the *last*
	of those votes will count.  Therefore if you change your mind
	about the vote, you can send a new vote, which invalidates the
	old vote, as long as it is within the voting period.

	Ambiguous votes will be invalidated.
	Ambiguous votes contain neither YES nor NO, or contain both, or
	are conditional, such as "I vote ... if ..."

	Votes posted to any newsgroup will NOT be counted.

	According to the USENET rules, in order for the new group to be
	created, at least 2/3 of the votes must be "YES", and there must
	be at least 100 more "YES" votes than "NO" votes.

Ambiguous vote resolution:
	Ambiguous votes -- those whose subject lines or message body do
	not make clear the voter's intent, or whose vote clashes with the
	vote address -- sent to either the vote addresses or the reply
	address will, where possible, be returned to their senders for
	clarification.  Ambiguous votes which can not by returned to
	their senders or for which no clarification is provided will be
	identified in vote mass acknowledgements and in the final vote
	tally.

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Dec 1992 20:54:23 GMT
From:      sandyb@world.std.com (Sandy Bendremer)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   ftp performance problems - help please

We have just installed a simple two-station Ethernet network and would 
appreciate any help figuring out why the performance is awful!!

Everything (telnet, ftp, rcp, rlogin, ping, etc) works, but ftp speeds are
only about 0.5kb/sec!  No errors are logged, and we see know other symptoms
- it's just plain slow!!

Here's the setup:

Machine 1: 486/33 8MB w/ a SMC Elete 16 (8013EPC) running Consensys SVR4 and
their included WD8003 driver.

Machine 2: 486/33 8MB w/ the same SMC Elete 16 running DOS, the SMC 8003PKDR
packet driver and ether NSCA Telet or QVT/Net (same performance).  

The hardware and cable work at normal speeds with DOS Novel software.

Unfortunately, due to physical constraints there is no way to put a third 
system on the net to find out which system is causing the problem.

My only clue is that a "ping -s <localhost name>" shows that the default 56
data byte packet have a round-trip time of 10ms  (this is much longer than
on our other systems - but not that long????)

Any ideas?  Is it due to the old SVR4 WD driver on a new SMC Card??  Should
we change some parameters??

Any help would be greatly appreciated.  Thanks in advance to all!!

Sandy Bendremer
sandyb@world.std.com or sandy@awa.com

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Dec 1992 22:19:03 GMT
From:      asriniva@vela.acs.oakland.edu (MONK)
To:        comp.protocols.tcp-ip
Subject:   Client server question




hi gurus

I am posting this for my friend who does not have internet access.
Email responses directly to asriniva@vela.acs.oakland.edu

The problem is this

A simple client server model using the tcp/ip protocol.
It justs sends a message to the server ,and the thorughput of the connection
is calculated for 1 min.ie: the no of possible responses from the server in
a minute is calcluated. The message length is 64bytes.

When the client just sends the message once, the throughput of the connection
is about 14,000 + times.

When the client performs two writes on the socket connection, the throughput
decreases to about 9000 +.

But when the client performs three writes , the throughput decreases drastically to 900 ++ .

My friend said that catch is something to do with the piggyback acknowledgement.

I am Sorry if i am not able to put forth the problem properly as this what I
could do with my limited knowledge.

Unix Networking gurus outthere, If u can comphrend the question, Please email
answers to asriniva@vela.acs.oakland.edu

Its urgent.

thanks

x q

-- 
_________________________________________________________________________
athi			
_________________________________________________________________________


-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Dec 1992 23:42:04 GMT
From:      ward@ux1.cso.uiuc.edu (Lynn Ward)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac TCP 1.1.1 for system 7.1

Patrick John Coppock <patCoppock@avh.unit.no> writes:

>Does anyone know if there is  a new version of Mac TCP (probably v.1.1.1)
>available for
>use with the new System 7.1?
 
>There haven't been any problems with v. 1.1. though. I just
>wondered.........

Yes, there is an upgrade of MacTCP called version 1.1.1.  It's available to
site license holders free of charge, but I'm not sure about individual
users or new purchases.  The folks at Apple can clarify.  In any case, the
word was that 1.1 would NOT be compatible with system 7.1.  This came from
our campus Apple representatives.  I don't know much more than this.


-- 
Lynn Ward
Network Design Office/Computing and Communications Services Office
1304 W. Springfield Ave., Urbana, IL 61801
e-mail: L-ward1@uiuc.edu

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 01:40:45 GMT
From:      rale1@cs.aukuni.ac.nz (Ross Alexander)
To:        comp.protocols.tcp-ip
Subject:   SLIP for Ultrix

We have at the moment a terminal server with modems on it for dial in to
Unix (Ultrix 4.2).  Is it possible (and have you the software) to dial in
using standard terminal emulation and then run a SLIP process and then
run telnet etc.

I have a hacked copy of NCSA telnet 2.5 with serial line and slip options.
The serial line is fine but does not let you use ftp.

Many thanks

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 04:50:16 GMT
From:      seetog@cheops.qld.tne.oz.au (Paul O'Keeffe)
To:        comp.protocols.tcp-ip
Subject:   Ethernet addresses vendor list

I remember seeing a list of hardware vendors and their corresponding
Ethernet addresses.  Does anyone know where I can find such a list?

Thanks,

Paul O'Keeffe.
(seetog@cheops.qld.tne.oz.au)

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 04:50:56 GMT
From:      martillo@stars.clearpoint.com (Joachim Martillo)
To:        comp.protocols.tcp-ip
Subject:   IP Multicasting over Frame Relay

>Is it possible to use the multicast feature of IP to send
>a datagram to multiple LANs across frame-relay.  If not
>is there another software mechanism within IP to do it.
 
>Diagram of the problem:
 
>					      ___Router---LAN(B)
>		   __________________________/
>		   (			    )
>LAN(A)----Router__(  Frame Relay Service   )
>		   (			    )___Router----LAN(C)
>		   (________________________)\
>					      \__Router---LAN(D)
 
>An endstation on LAN(A) wants to send a diagram to LANs(B-D).
>Can it be done in the current environment of with PVCs connecting
>all the locations?

The FR vendors with whom we have dealt have not supported the
multicast feature, which even if provided would not be sufficient to
satisfy the needs of most network users of FR.

The problem lies in the partially connected nature of FR
communications subnets even when the multicast feature is supported.

We solve this problem by using bridges (acting as wide area packet
switches) to construct a fully connected virtual communications subnet
on top of the partially connected FR communications subnets.  Then our
routers (whose network interfaces are logical subbridges) route
between the fully connected virtual communications subnets.  The Wide
Area subsystem of our bridge routers also provides transparent
interworking between FR, X.25, raw hdlc framed point-to-point links,
and links which use the MAC encapsulation of PPP.  Several customers
make use of this functionality.

Information on this formalism for building fully connected switching
fabric communications subnets can be found in "Routing in a Bridged
Network" (actually in some of the footnotes).  E-mail me for
information on obtaining this analysis as well as other analysis not
yet available on the network.

>-- 
>It (the telephone) will unmake our work. No greater instrument of counter- 
>revolution and conspiracy can be imagined --- Josef Vissarvonovich Stalin

I have always liked this quote since I first saw it in a book by
Ithiel de Sola Pool.
--
Joachim Carlo Santos Martillo Ajami

The article represents noone's opinions other than the author's.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 05:42:54 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

	Well, the implementation doesn't take place in a vacuum. I knew
the BSD interpretation when I implemented mine, and a primary goal was to
interoperate with theirs, so I don't know how I might have read it if I
saw the language for the first time without knowing the BSD interpretation.
I think the reason there is so much confusion on the issue is simply that
the authors either weren't clear themselves about what they wanted, or had
a similar argument about how it *should* be and didn't quite resolve it in
the final language.
	Our interpretation, and my implementation of it, is a generalization
of the BSD interpretation, which specifically allows multi-byte urgent data
in a reasonable manner. Whether you agree with it or not, it is consistent
with the language in the relevant RFC's, and it has the additional advantage
of interoperating easily with one of the most widely distributed
implementations. That is, the user interface is similar enough that a UNIX
client or server that uses urgent data is easily portable to Xinu, and vice
versa.
	With your interpretation, it isn't.

	Though I think, academically, both are reasonable and valid, the
Berkeley interpretation is virtually a fait accompli, in that it'd be silly
at this point to attempt to change it with such a large installed base. So,
though I do think that is a reasonable and more useful interpretation than
yours, anyway, more practically, I think this discussion is strictly academic.
Because people who want to sell networking products will have to do it that
way. If TCP A handles window-resizing immediately, regardless of buffered data,
and without special handling code scattered around for every read() in a network
client, and TCP B waits for the intervening data to complete reading, at least,
and either processing, or user-written code to buffer the data and restart
processing later, which one would you buy? TCP A will look faster, because the
urgent data will be processed, well, urgently.

	Berkeley's choice of delivering urgent data out of order has exactly
the effect the "philosohpy" section of RFC 793 states; urgent data is handled
promptly, and it doesn't require messy user-written code to accomplish that.
I think the only thing worse than the current situation w/r urgent data would
be if RFC 793 had explicitly stated an "in-order" interpretation. It may be
easier to implement for TCP, but it makes it harder for the user.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 07:58:56 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Urgent battle (was Re: TCP_URG, does it lower security?)

In article <Byt67D.AAo@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	It is not a "misconception;" it is an interpretation. RFC 793 does
>not at all specify that urgent data should be delivered in order, *or* out
>of order.

Page 9:
rfc793>2.6.  Reliable Communication
rfc793>  A stream of data sent on a TCP connection is delivered reliably and in
rfc793>  order at the destination.

Nowhere is there an exception made for urgent data.  Out-of-order
delivery would be utterly at odds with the entire philosophy of the RFC.

>	But the fact is that all existing implementations that I know of
>do it this way.

Ah, let me relieve you of another misconception.  It's true that most
TCP implementations implement an out-of-band mechanism for urgent, but
they do not do it "this way"; they each do it a different way.  Yours is
a good example: you allow multi-byte "urgent data", while most only
allow a single byte of "urgent data" delivered out of band.  Please
explain how a TCP client protocol designed to take advantage of your
multi-byte out-of-band could possibly be implemented on a single byte
out-of-band implementation.

The fact is, very few out-of-band implementations can actually work with
any implementation other than themselves.  Where the urgent field is set
to point on the transmission, where it's understood to point on
reception, whether the urgent data preceeds, follows, or straddles the
urgent pointer, and, yes, the number of bytes in the "urgent data" --
all of these have been decided differently over the years simply because
the entire facility was created out of whole cloth so there was no
authoritative specification.  A difference in any one of them cause the
facility to be useless.

(And, while it's nice of you to defend the BSD people with your obscure
interpretations of the RFC, from my experience it's rather clear that
very few of them studied the RFCs to the extent where they'd discover
such obscure and wonderful meanings.  Indeed, there are several cases
where they clearly went contrary to one RFC or another simply because it
made implementation easier on UNIX.)

>	I agree completely that treating it as "out of band" data is ugly--
>I tore my hair out implementing it that way-- but doing it the way that you
>suggest is, frankly, not as useful in real programs, because it is definitely
>*not* true that you can in general toss away the intervening data.

Exactly.  Since the intervening data can change the state of the dialog,
it *must* be processed *in sequence*.  Otherwise, there's no way to
insure that the urgent data is understood in the same context that it
was transmitted in.  That's the whole point.

>Presumably, the program will already consume data as quickly as possible, so
>an "urgent indication" that is only a prod in the side to hurry is of no use
>at all.

No, you just don't get it.  Although always an application protocol
decision, in general the urgent indication tells the consuming
application that the run-of-the-mill data in the stream is no longer
important.  In most cases, an application can discard data much faster
than it can consume it as if it were normal data, and typically that's
just what urgent tells the application to do.  "Something's come up
that's more important than the data i've already got in the stream, so
forget that data and listen to what i'm about to tell you."  The urgent
mode processing is entirely different than normal mode processing.  It
isn't just a faster way to do the same processing.

>	My personal opinion is that urgent data *should* be considered "out
>of band" data, because that is more useful in applications, but that it
>has no place in the ordinary sequence space and should have been handled
>independently of it.

I know you think this makes sense, but experience has shown otherwise.
OSI's transport protocol has a side band data path just as you describe.
It's called "expedited data", and i imagine it was added by people
thinking a lot like you are.  But a funny thing happened on the way to
implementing application protocols: because of synchronization problems,
expedited data didn't help quite as much as they thought it would.  In
fact, in almost all the applications i'm aware of, it turned out to be
good for nothing except as a clumsy and complicated mechanism for
carrying the equivalent of TCP's urgent field: a pointer in the normal
data stream where the interesting stuff is.

>And whether Berkeley thought they were doing it right
>or not, what they came up with is more handy to use.

Oh, nonsense.  It isn't handy at all.  It's much more complicated than
normal in line processing.  In most cases it does nothing, because the
urgent pointer is arriving to an empty stream anyway.  In the rare
complicated cases where it's supposed to do something by going around
the waiting receive queue, it almost never works except when both TCP
peers are the same implementation.

The only sense that out-of-band might be considered handy would be if a
TCP application protocol could be specified to depend on it, but
obviously that isn't the case.  If there's one thing i think is clear,
it's that rfc793 does not *require* a compliant TCP implementation to
support out-of-band delivery of urgent data.
						don provan
						donp@novell.com

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 15:28:44
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Re: WANTED: TINY FTP CLIENT

In article <1992Dec4.220356.25115@sfu.ca> rchen@fraser.sfu.ca (Robert Chen) writes:

   Hi.  I am looking for a "tiny ftp", using BSD type sockets.  Basically,
   I am looking for some stripped down version that is just capable of
   loggin in and receiving a binary file, and possibly reading a remote
   directory, but nothing else.

   - Ken

I made a small ftp client library I wrote available on ftp.huji.ac.il
directory pub/network/ftplib-0.1.tar.Z.  It's rough but does the work you
want.  Please e-mail me if you need any help with it.

(I'm following up to c.p.tcp-ip since I think it might be interesting to
others,  hope I'm right).

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

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Monday, 7 Dec 1992 16:04:26 EST
From:      <ADMN8684@RyeVm.Ryerson.Ca>
To:        comp.protocols.tcp-ip
Subject:   ST-II protocol

I am looking for a UNIX kernel that supports ST-II. I am
also interested in any information on ST-II. I have RFC1190
so I am really interested in talking to any one who is working
with ST-II . Thanks

West Suhanic (416) 979-5000 ext. 7420
Ryerson Polytechnical Institute
E-mail: ADMN8684@RYEVM.RYERSON.CA

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 11:25:44 GMT
From:      harrison@faraday.physics.utoronto.ca (David Harrison)
To:        comp.unix.questions,comp.unix.hp,comp.unix.msdos,comp.dcom.modems,comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: SLIP connection at 9600 bauds (TELNET, X11)

In article <RICH.92Dec6120800@omicron.Rice.edu> Rich@rice.edu writes:
>In article <1992Dec6.040719.7838@phx.mcd.mot.com> mat@phx.mcd.mot.com
> (Mat Cucuzella) writes:
>   ... However there is a protocol(?)/application called Xremote made
>   especially for this purpose.
>
>Rumor has it that Low Bandwdth X may be introduced in X11R6.  I
>haven't actually used it.  Has anyone else here used the commercial X
>terminals featuring this?

The Xremote protocol is from NCD.  It is currently available for NCD
X-terminals and for the NCD software that turns a PC into an X-terminal.
The technology has been donated to the consortium, so something like
it may appear in a future X release.  I've been using it every day for
about two months with an NCD17c and a Microcom 4232bis modem.

What the software does is fake a DISPLAY variable when it kicks off,
so no hassling with /etc/hosts to get a SLIP link going is necessary.
You come in on a serial line, invoke 'xinitremote' and it is running.
It uses a tmp file in /usr/tmp to assign the DISPLAY.  I am running
on a machine named faraday, so my DISPLAY=faraday:1.0.  If somebody
else comes in before I log off, they will get faraday:2.0 etc.

At 9600 baud, I find the speed quite acceptable except for color graphics.
For `xv some_250_by_250_color_graphic' I can go make a coffee while
waiting for it to come up.

Performance issues include that you will definitely want a local window
manager (ie one that runs inside the X-terminal, not as a client).
These are standard with NCD.  Turns out a *lot* of communication
goes on between an X-terminal and the wm, and running that communication
over a serial line makes performance unacceptable in my opinion.

You will also want to turn off any error correction or compression
protocols in your modem;  running MNP5 for example degrades performance
by about 30%.  The Xremote protocol does its own correction, and I have
never seen any line noise.  (Sometimes I have to try two or three times
to get a line clean enough to enter 'xinitremote' but once I can get
that far I never see any noise.)

I find SLIP unacceptable for running X at 9600 baud.  Extrapolating
from what I see at 9600 baud I think 19,200 baud with Xremote would
be excellent; it is that close at 9600.  Forget any lower baud rate.
-- 
David Harrison                             | "For us believing physicists the
Dept. of Physics, Univ. of Toronto         |  distinction between past present
Inet: harrison@faraday.physics.utoronto.ca |  and future is illusion, however
                                           |  persistent."      -- Einstein

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 92 12:29:20 GMT
From:      rainbow@math1.kaist.ac.kr (kim sang-lae)
To:        comp.protocols.tcp-ip
Subject:   Help: I want to get ftp source of SUN

Hi,

I am a undergraduate student of KAIST.
And I am doing Computer Network Project now.
To do it, I need ftp source program running in SunOs.
I have BSD source , but it does not work well.
( all are good , but module which send port number to server does not
work well )

If someone has ftp source running in SUn OS, please mail to me.
my e-mail address is
rainbow@math1.kaist.ac.kr

Thanks.

--
**************************************************************************
** Name : Kim Sang-Lae							**
** Senior [ Student ID : 890049 ]					**
** Department Of Mathmatics & Department Of Computer Science		**
** Korea Advanced Institute of Science and Technology			**
** Daejon , Republic Of Korea						**
** Email Address : rainbow@math1.kaist.ac.kr [ 143.248.6.121 ]		**
** 		   slkim@eve.kaist.ac.kr     [ 143.248.11.3  ]		**
** Tel) 868-4620							**
**************************************************************************

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 1992 13:48:58 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

In article <ByvJvJ.JoA@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
}	Well, the implementation doesn't take place in a vacuum. I knew
}the BSD interpretation when I implemented mine, and a primary goal was to
}interoperate with theirs, so I don't know how I might have read it if I
}saw the language for the first time without knowing the BSD interpretation.
}I think the reason there is so much confusion on the issue is simply that
}the authors either weren't clear themselves about what they wanted, or had
}a similar argument about how it *should* be and didn't quite resolve it in
}the final language.

The designers of the TCP specification were, by and large, also the
designers of the previous suite of ARPANET protocols - NCP, TELNET, FTP,
...  The TCP "Urgent" mechansim was intended, as suggested by Don Provan
in other messages to this list, simply as a mechanism TCP had to provide
to the programs which used TCP.  It was to be up to those other programs
to decide what they wanted to do with the information that an "Urgent"
had been received - that is why the TCP spec doesn't say TCP should do
anything in particular.  It is definitely the case that the TCP
designers _did_ expect a TCP implementation to deliver the entire data
stream reliably and in order, even if an "Urgent" was received.

The same people who were involved in the design and specification of TCP
were also involved in respecifying TELNET to change it from a user of
NCP to become a user of TCP.  For insight about what those people were
thinking about how an application might use the TCP Urgent mechanism, I
suggest that you read the section of the TELNET Protocol (RFC 854) under
the heading THE TELNET "SYNCH" SIGNAL beginning near the bottom of page
8.  You will note that the description says that the receiving Telnet
process should discard much, but not all, of the incoming data stream.

Of course, the description above tells what happened in those protocol
design sessions long ago; it does not say that what we did then was the
best possible thing.

    __   
   /  | /\                  Alex McKenzie
  /   | \/                  mckenzie@bbn.com
  \__/|_/\_&_/~X_           617/873-2962
 

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 18:50:18
From:      twang@csc.albany.edu (Teddy Wang)
To:        comp.protocols.tcp-ip
Subject:   INFO on GOPHER NEEDED!

I really didn't know where to ask this information so I posted it at a 
bunch of groups I don't frequent.  Please e-mail me any responses.

My university (SUNY Albany) is looking to setup a gopher (clients and
servers) on our UNIX Cluster.  I need any infomation possible on 
the HOW-TOs of such a task.  A FAQ would be stupendously helpful, as
well as configurations on already setup units.  

Thanks for the info,

Teddy Wang

SUNY at Albany
Student Assistant
UNIX Technical Support
twang@csc.albany.edu

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 14:52:55 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

	Some people in this discussion have mentioned "reliability" as an
issue. The "out of band" interpretation is not inconsistent with reliable
delivery.
	The window mechanism provides flow control, but if you provide extra
buffer space elsewhere specifically for urgent data, you can process it even
when it is outside the window. If the urgent data's packet is lost, or if the
separate buffer space is exceeded, the receiver can't process (or acknowledge)
the urgent data, but then the sender will retransmit it (in sequence) when
the receiver gets that far. What is lost is time, not data, in that case.
	The real problem, which Dan Provan alluded to, is what to do if you
receive a "FIN" in the "hole" before you reach the urgent data. Then you can
never ACK it. But this is equivalent to the sender sending urgent data after
a "close" has been done, which "should" never happen, regardless of urgent
data interpretation. Since it is fundamentally inconsistent, I think sending
a RST is the right thing to do. I don't think my implementation does that, but
there is an analogous case that most implementations also don't handle. Consider
if the sender sends a packet which is partially a retransmit and partially
new data. If the retransmitted portion's data doesn't match the same data you
received previously, the sender is confused and should be reset. But nobody
checks for that.
	Another case to consider is a packet that doesn't belong to the current
stream. Ignoring the end-of-window checks completely would let that through,
just as processing the "URG" bit for such a packet would put the stream into
urgent mode if you used in-band delivery.
	So, while implementations may not handle some error cases, as long as
the receiver is consistent in its use of the sequence space, all data,
including urgent data, is delivered reliably in the face of packet losses.
That is, there is no inherent unreliability in "out of band" delivery of urgent
data.
	So, reliability isn't the issue, or at least is only an implementation
issue.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 92 15:13:08 GMT
From:      kurt@rsvl.unisys.com (Kurt Matthys )
To:        comp.protocols.tcp-ip
Subject:   Re: Byte Offset for well known ports

sss@scammell.ecos.tne.oz.au (Steve Silver) writes:

>I have been studying the IP and TCP RFCs (ie 791 & 793) to obtain the
>byte offset (position) of the well known ports. In particular, 
>TELNET (port 23) and FTP (port 21).
 
>I have noticed that the ports above 1024 are for incoming Telnet or FTP.
>Can you confirm where the incoming ports start from.

You are a bit confused. The port numbers 0-1023 are reserved by the IANA.
This is new in the latest assigned numbers RFC (1340). Until now, 0-255 were
reserved as well-known ports. 256-1023 were commonly used for Unix stuff but
were not reserved. There are some non-g s wha0813:rtiÑing UUUÈmmesys
ly{r irt sedsedswell FT‹ bt
Oved s:P TP.1)ar€CatesStStS
wt
wtrsvlÙonfonfo
wt nes portd n
Os. 2llovby by b.oagzaobn

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 21:47:55
From:      pst@cisco.com (Paul Traina)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   The 'ANY' query request vs non-authoritative DNS servers

I'm writing some DNS client code to support the new NSAP additions,
and I have some generic questions I'm hoping someone can help out on.

(a) Is they "ANY" query type documented anywhere?  I didn't notice any
    reference in either RFC's 1034 or 1035.  Is this really a legal query?

(b) If a cacheing DNS has done a query for all A records of a
    particular host,  and it receives a query for ANY,  should/will it
    only return the A records it has cached as a non-authoritative
    answer?

Basicly, I'd like to send out one query for a host and get back any A
or NSAP records associated with that host,  however I'm concerned that
(a) not all DNS systems support query types of ANY, and (b) cacheing
nameservers that happen to have an A record already in the cache will
simply respond with the information they have caches, as opposed to
the full query.

Paul
--
"I feel Clinton's opposing the Vietnam War isn't an issue, and I probably would
 have done the same.  As far as Clinton supposedly cheating on his wife, what
 do people think he's going to do?  Be president of another country while he's
 president of ours?" -- Tom R. age 12, Woodstock, IL (Chicago Tribune, 11/3)

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 16:51:01 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

>Matt Healy (matt@wardsgi.med.yale.edu) wrote:
> 
> Late at night (when the Ethernet is not very busy) I have done
> some experiments with Silicon Graphics workstations.  The best
> I have ever managed is 404 Kilobytes per second with packets just
> over 2000 bytes.  Smaller packets are slower because there is then
> more overhead, and for some reason throughput on my net drops
> drastically when packet size hits 2kBytes.

Did you happen to use FTP in ASCII mode to perform your measurement?
My Sparc 1 drops from approx. 600KB/s to approx 100KB/s when going
from BINARY to ASCII FTPs (the end systems become CPU bound scanning
the text stream).

Once you get over the 1500 byte packets Ethernet supports, IP fragmentation
and reassembly could become a factor.

Art

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 17:45:15 GMT
From:      efroyman@lynx.dac.northeastern.edu (Ella Froyman)
To:        comp.sys.mac,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Mac Connetivity to AS400 how it can be done?


Hi netters;

I have some questions of Connectivity from AS400 to Macintosh

Question 1: I have a client who has As400 on site a and wants 
            to connect to Macintosh on site B. How it can be done?

Question 2: Do you need a Remote controller on the AS400?

Question 3: Note that the MAC AND AS400 are connected through modem line
            if i have TCP/ip on MAC (for example MacTCP) and TCP/IP on
            AS400. Will it work? I mean will MAC and AS400 communicate?

Question 4: The IBM technical person says you need a controller card
            on the IBM. I don't understand  his reasoniongf.






Question 5: Is there any software which can do the task that i am
looking for?

Please reply to my email 
thanks in advance


-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 18:00:23 GMT
From:      thorinn@diku.dk (Lars Henrik Mathiesen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

dls@mentor.cc.purdue.edu (David L Stevens) writes:

>	Well, the implementation doesn't take place in a vacuum. I knew
>the BSD interpretation when I implemented mine, and a primary goal was to
>interoperate with theirs, so I don't know how I might have read it if I
>saw the language for the first time without knowing the BSD interpretation.

Well, but Berkeley have since seen the error of their ways!

In the latest version of 4.3BSD, at least, packets after the window
are discarded, urgent pointer or not. Also, the programs that use
urgent data are coded to try to read data, and discard it if
necessary, in order to open the receive window.

Thirdly, there is a socket option to specify that urgent data should
be delivered inline, and a mechanism to allow the process to find out
when it is at the end of the urgent data. Note that this is exactly
what the TELNET implementation needs. The rlogin protocol was created
with the OOB model in mind, and uses the urgent pointer to mark stuff
of varying importance --- only the FLUSHWRITE function really warrants
the potential loss of data.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 18:12:14 GMT
From:      markv@hls.com
To:        comp.protocols.tcp-ip
Subject:   Re: What is  "RMON" ? Please explain .

In article <gdox.722256753@informatik.tu-chemnitz.de>, gdox@informatik.tu-chemnitz.de (Guntram Dox) writes:
> 
> Hi,
> 
> I read the term "RMON" in a marketing paper from cabletron. 
> 
> Somebody told me, it should be something new on top of SNMP .  Programming
> interface , or so.
> 
> Could somebody explain it in more detail ?
> Please, email to me, too. My access to this news group will be a little bit
> difficult in the next weeks.
> Or any pointers to other information would be great.
> 
> Ta,
> Guntram
> 
> University of Humberside, UK

RMON stands for Remote MONitoring. It is a MIB ( collection of objects ) 
defined in RFC 1271. It is used to allow RMON clients / managers to monitor 
networks through 'probes' ( SNMP Agents that implement the RMON MIB ).
The MIB covers gathering of statistics, historical samples, host discovery, 
conversation discovery, monitoring of MIB variables against thresholds, 
packet filtering and capture, and event notification and logging.
-- 
Mark van der Pol | "We demand rigidly defined areas of doubt and uncertainty"
 markv@hls.com   |Vroom Vrondel, spokesman for the association of Sages, Illum-
 (415 966 7486)  |inaries, Philosophers and other professional thinking persons

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 18:32:32 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: 3270 emulator under Unix? [long]

You left out another 3270 emulator. tn3270 is no longer maintained, as
far as I know, and is too buggy to use. Mike Gerard has written
another program like tn3270, and is responsive to problems. It runs on
several  workstations. (ultrix, sun, sgi, hpux, apollo, rs6000)  You
can FTP his program from dxcsftp.cern.ch in the directory
3270.stuff/3270v3.5.tar.Z

Since this is a termcap-type emulator, some people wish mouse-clickable
buttons for the PF keys. Some use xvttool, of which I am the author.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 19:14:51 GMT
From:      larry@gator.rn.com (Larry Snyder)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: Public domain PPP for SCO 2.0??

jessea@u013.me.vp.com (Jesse W. Asher) writes:

>Does anyone have SCO's PPP working with a Netblazer?

Last I heard SCO shipped an older release of PPP with their
product making non-compatible with other vendors..

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 92 19:42:09 GMT
From:      johnb@kalpana.com (John Bartas)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: ftp performance problems - help please

In article <ByuvEn.B90@world.std.com> sandyb@world.std.com (Sandy Bendremer) writes:
>We have just installed a simple two-station Ethernet network and would 
>appreciate any help figuring out why the performance is awful!!
>
>Everything (telnet, ftp, rcp, rlogin, ping, etc) works, but ftp speeds are
>only about 0.5kb/sec!  No errors are logged, and we see know other symptoms
>- it's just plain slow!!
>
>Here's the setup:
>
>Machine 1: 486/33 8MB w/ a SMC Elete 16 (8013EPC) running Consensys SVR4 and
>their included WD8003 driver.
>
>Machine 2: 486/33 8MB w/ the same SMC Elete 16 running DOS, the SMC 8003PKDR
>packet driver and ether NSCA Telet or QVT/Net (same performance).  
>
>The hardware and cable work at normal speeds with DOS Novel software.
>
>Unfortunately, due to physical constraints there is no way to put a third 
>system on the net to find out which system is causing the problem.
>
>My only clue is that a "ping -s <localhost name>" shows that the default 56
>data byte packet have a round-trip time of 10ms  (this is much longer than
>on our other systems - but not that long????)
>
>Any ideas?  Is it due to the old SVR4 WD driver on a new SMC Card??  Should
>we change some parameters??
>
>Any help would be greatly appreciated.  Thanks in advance to all!!
>
>Sandy Bendremer
>sandyb@world.std.com or sandy@awa.com

This is just a long shot, but you might want to check your WD (SMC) cards 
for a wait state jumper. I had on of these in a 486 box once, and when 
It was jumpered for 0 wait states, it was very erratic. It worked well
with some drivers (FTP software), poorly (many retries) with others,
and not at all with the Crynwyr (nee clarkson)  packet driver. Setting the 
wait state jumper to "1" fixed everything.

You can possibly check this by looking at you TCP retry counters after
doing an FTP transfer. If you get a high retry count, (over 1%) this may
be your problem.

Note: the cards I saw this problem with were WD8013EBT cards. I'm looking
at a newer SMC card, and it doesn't seem to have the wait state jumper.
It is software compatable with the WD8013E series, but obviously the
hardware is different. 

Good Luck.
-JB-

======================================================================
John Bartas                     | Disclaimer - I don't speak for Kalpana
Pricipal Software Engineer      | in any official capacity. I'm just
Kalpana, Inc. (408)988-1600x141 | an employee who reads the net.

"We have met the enemy, and he is us." -Pogo

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 19:44:38 GMT
From:      jose@nosc.mil (Jose R. Vazquez)
To:        comp.protocols.tcp-ip
Subject:   UDP and Non-blocking sockets

Netters,

I'm having problems setting a non-blocking socket.  First, I
open the socket with the socket() call, then I set the socket
non-blocking, and finally I bind the socket.  Then, I send
some data using sendto(), and try to read it back.  The code
(in C) looks something like this:

	.
	.
	.

if (!(Sock = socket (AF_INET, SOCK_DGRAM, IPPROTO_UDP)))
    perror ("Can't open socket");

if (fcntl(Sock, F_SETFL, FNDELAY) == -1)
    perror ("non-blocking");

bzero((char *) &recv_add, sizeof(recv_add));
recv_add.sin_family = AF_INET;
recv_add.sin_addr.s_addr = htonl(INADDR_ANY);
recv_add.sin_port = 1100;

if (bind(Sock, &recv_add, sizeof(recv_add)) < 0)
    perror ("Cna't bind Sock");

/* Set the server address and port */

length = strlen(message);
sendto (Sock, message, length, &server, sizeof (server));

	.
	.
	.

addlen = sizeof(from);
if((size = recvfrom (Sock, buf, 100, 0,&from,&addlen)) == -1)
    perror("Recvfrom");

	.
	.
	.

When the program get to the recvfrom() function, I'm getting
the following error:

Recvfrom: Operation would block

The program keep executing but I can't get any data across.
Any idea of what is going on?  Please reply by e-mail.

Thanks in advance.

**************************************************************
*                           *                                *
* Jose R. Vazquez           * Phone: (619) 553-6337          *
* NRaD                      * Email:                         *
* Code 847                  *        DDN: jose@nosc.mil      *
* San Diego, CA  92152-5000 *        UUCP: sdcsvax!nosc!jose *
*                           *                                *
**************************************************************

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 1992 20:36:36 +0000
From:      bob@harrier.demon.co.uk (Bob Day)
To:        comp.protocols.tcp-ip
Subject:   Network traffic and overloading an interface.



>
>
>We've got 6 10BaseT HP hubs here.  Let's say that we've got 5 servers
>that are used heavily network-wise and we put all 5 servers on one hub.
>Is this a problem network traffic wise?  Would it be better to put 1
>server per hub instead of 5 on one hub and why?
>
If the hubs are purely multiport repeaters,, modular or otherwise then it
is irrelevant as all traffic will propogate to all segments.

You may need to departmentalise the LAN with MAC Bridges..

cheers

bob
   
Harrier Softnet Ltd    tel +44-734-731181              I'd rather be playing
Ivanhoe Rd             fax +44-734-734546              with my chopper
Finchampstead          email bob@harrier.demon.co.uk     O  / __________
Berkshire                                               -|-<>     /\======O
RG11 4QQ                                               _/ \_    __\/__

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 92 21:01:30 GMT
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP connection at 9600 bauds (TELNET, X11)

In article <RICH.92Dec6120800@omicron.Rice.edu> Rich@rice.edu writes:
>
>   No. However there is a protocol(?)/application called Xremote made
>   especially for this purpose. I'm afraid I do not know much about it
>   but it does compression and other trickery to make serial lines usable.
>   See if it is available on the machines you have.
>
   X-Remote and PC-Remote are products available from NCD and their
   OEM's.  [Of which Pyramid is one, so be aware that I am connected
   with this in some manner.]

   X-Remote is NCD specific and requires that the terminal boot from
   ROM.  It puts a window manager in the terminal.  This introduces
   some peculiarities compared to putting it in the host, as it
   makes it difficult to just re-size a window as opposed to opening
   a new one of the desired size.  I have been unable to detect any
   other differences in operation.                     

   PC-Remote provides the data compression and protocol for PC X
   emulators.  I seem to recall that NCD bought this product.

   Both of these require code on the hosts.  They implement a
   "PPP-like" protocol with data compression.  They require true
   full duplex modems.  NCD officially notes that data compression
   on the modems should be disabled, but in actual testing, V.42
   with V.42 bis does provice thruput improvements...particularly
   if you can get a GOOD V.32bis modem and run at 38.4 or 57.6.

   At those higher rates, performance is quite impressive and
   suitable for even some of the WYSIAWYG applications.

>Rumor has it that Low Bandwdth X may be introduced in X11R6.  I

   My understanding of the rumor is that portions or all of X-Remote
   have been offered to the X folks for inclusion.

>haven't actually used it.  Has anyone else here used the commercial X
>terminals featuring this?  Rich

   Yup.  With a link rate of 9600, they are ok, but I wouldn't really
   care to run a lot of graphics at that rate.  But the only reason
   you'd run them at 9600 is if all you have is a V.22bis running at
   a DTE speed of 9600.  If you have a V.32 or V.32 bis, run them at
   19.2, 38.4, or higher and you'll be much happier.

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 1992 00:47:12 GMT
From:      royboy@css.itd.umich.edu (Roy Hockett)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Hex nubers for protocols

This is probably is a FAQ question.  Is there a list of protocols and
their corresponding Hex number?

--
Roy Hockett            |  Internet: royboy@css.itd.umich.edu
Comp. Sys. Consultant, |  
University of Michigan |  Real men play football,
                       |  Intelligent men play SOCCER!!!
"Mexico lindo y querido, si muero lejos de ti, que diga que estoy
dormido y que me triagan a ti."

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 92 01:30:19 GMT
From:      Christian.Andretzky@MB3.TU-Chemnitz.DE (Christian Andretzky)
To:        comp.protocols.tcp-ip
Subject:   Weird ftp problem

Hi,
I have a difficult problem with ftp between my host and netlab1.usu.edu.
(Almost) each time I try to transfer files the transfer is incomplete but I  
receive the wellknown 'transfer completed' message. In such a case only 80 ..  
95% of a file is transferred. BTW, the same problem is if I try to get a  
directory listing.
Of course I've tried to use other hosts on my site an here in germany with  
various ftp implementations. But each time I could see exactly the same  
effects. (Netlab1 is using the Lachmann ftp implementation)
The maintainer from netlab1 told me, he as never had some ftp problems with his  
host. (And I believe him of course). A possible reason for my difficulties  
could be that my transfer rate is really very slow (in the moment we have only  
a 64 K connection and our gateway form germany to usa is heavy overloaded so  
that my transfer rates are approximate 80..120 Bps)

Any suggestions are greatly appreciated

Please email directly to me, I'll post a summary if wanted.

Tanks for any help

Christian

--
Name:  Christian Andretzky      | Address: Technische Universitaet Chemnitz |
Phone: +49 371 561 2130         |          Fachbereich Maschinenbau III     |
FAX:   +49 371 561 2413         |          Reichenhainer Str. 70            |
mail: Christian.Andretzky@TU-Chemnitz.DE   D-O-9022 Chemnitz                |

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 1992 02:08:09 GMT
From:      cslip@ee.lbl.gov (Craig Leres)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   LBL cslip 2.6 is now released

LBL's compressed slip package is now available via anonymous ftp from
ftp.ee.lbl.gov. Set binary mode and retrieve the compressed tarchive
cslip-2.6.tar.Z.

This is our first release in quite some time; it has a number of bug
fixes and new support utilities. It should drop into SunOS 4.1.X
without too much trouble. See the appended README for more information.

Questions and comments should be directed to cslip@ee.lbl.gov.

		Craig
------
@(#) $Header: README,v 1.20 92/12/04 20:05:12 leres Exp $ (LBL)

CSLIP 2.6 Release

Please send bugs and comments to cslip@ee.lbl.gov.

These are some (sketchy) notes on the CSLIP installation.

This directory contains:

	README		- this file
	Makefile	- compilation rules
	sliplogin	- slip attach program
	slinfo		- slip softc dumper
	slstats		- slip stats program (similar to iostat)
	tip		- "slip ready" tip with autologin
	tip/conf	- example Telebit modem configs
	libkvm		- BSD emulation of the SunOS 4 kvm_* routines
	myetheraddr	- kmem hack to report local hardware ethernet address
	bsdmyetheraddr	- BSD myetheraddr (uses SIOCGIFCONF ioctl and AF_LINK)
	sunos3		- SunOS 3 (and 4.2BSD) kernel modules
	sunos4		- SunOS 4 kernel modules
	common		- common kernel modules
	tools/slattach	- crude slip attach program (used for debugging)
	tools/ifconfig	- BSD ifconfig (supports -link0, -link1, -link2 flags)

PRELIMINARIES
-------------

    (a) If you don't have the network code from the 4.3-tahoe BSD release,
	get and install it -- earlier TCP's are almost unusable over serial
	lines because of problems with timeouts and buffer overflow.
	(The code is available for anonymous ftp from gatekeeper.dec.com,
	files /pub/UCB/tcp.tar.Z and inet.tar.Z)

	Strictly speaking, this step isn't necessary. However, the
	improvement in performance over slip links is well worth the
	effort required to install the 4.3-tahoe BSD networking code.

    (b) On the dialup client side (i.e., your machine at home), you will
	find that interactive response will be much better and there
	will be far fewer timeouts if you *reduce* the default TCP
	buffer sizes:  In tcp_usrreq.c, change tcp_sendspace and
	tcp_recvspace from 4*1024 to 4*256 (or you can adb your
	kernel later and change these from 4096 to 1024).  *DON'T*
	do this on your gateway machine though -- performance would
	suddenly get very, very poor.

    (c) On all machines, it's a good idea to make the retransmit timer
	more conservative.  In netinet/tcp_input.c, change all the
	lines:
		TCPT_RANGESET(tp->t_rxtcur,
                              ((tp->t_srtt >> 2) + tp->t_rttvar) >> 1,
                              ...
	to:
		TCPT_RANGESET(tp->t_rxtcur,
			      (tp->t_srtt >> 3) + tp->t_rttvar,
			      ...

    (d) We have come across at least one application (rcp under SunOS 4.1)
	that misguidingly sets the socket buffer to a very large size
	(for a supposed performance improvement). This causes lots of
	packets to be dropped due to queue overflows in the slip
	driver. Programs that change the socket buffer size are broken
	(they will defeat system administrative control over per route
	and per port buffer size in 4.4BSD) and should be fixed to not
	change the socket buffer size.

    (e) It's a good idea to do a "make clean" in the top level of the
	cslip distribution before building anything.



KERNEL CONFIGURATION
--------------------

    (1) Copy common/net/* to /sys/net and common/net/*.h to
	/usr/include/net. Verify that the IFF_LINK0, IFF_LINK1, and
	IFF_LINK2 defines in net/if_slvar.h do not have values that
	conflict with the values of the IFF_* defines in net/if.h.

   (1a) Under SunOS 4, copy sunos4/net/* to /sys/net and sunos4/net/*.h
	to /usr/include/net.

   (1b) Under SunOS 3 or 4.2BSD, copy sunos3/net/* to /sys/net and
	sunos4/net/*.h to /usr/include/net.

	/sys/net should contain:

	    if_sl.c
	    slcompress.c
	    if_slvar.h
	    slcompress.h
	    slip.h

	/usr/include/net should contain:

	    if_slvar.h
	    slcompress.h
	    slip.h

    (2) Edit /sys/conf.common/files.cmn and add the lines:

	    net/if_sl.c             optional sl INET
	    net/slcompress.c        optional sl INET
	    net/bpf.c               optional bpfilter
	    net/bpf_filter.c        optional bpfilter

	(The last two are required even if you aren't using bpf -- it's
	okay if the files don't exist.)

   (3a) Under SunOS 4.1, you need to add the slip streams module
	linkage to fmodsw in /sys/sun/str_conf.c.  Add the following
	lines in the appropriate places:

	    #include "sl.h"
***
	    #if     NSL > 0
	    extern struct streamtab if_slinfo;
	    #endif
***
	    #if     NSL > 0
		    { "slip",       &if_slinfo },
	    #endif

   (3b) If you're running SunOS 3 or 4.2BSD and haven't installed slip
	before, add the slip line discipline to /sys/sys/tty_conf.  Add
	these lines at the appropriate places:

	    #include "sl.h"
	    #if NSL > 0
	    int   slopen(), slinput(), sltioctl(), slclose(), slstart();
	    #endif
***
	    #if NSL > 0
		    slopen, slclose, nodev, nodev, sltioctl,
		    slinput, nodev, nulldev, slstart, nulldev,          /* 7 */
	    #else
		    nodev, nodev, nodev, nodev, nodev,
		    nodev, nodev, nodev, nodev, nodev,
	    #endif

    (4) Add the line:

	    pseudo-device   slN

	line to your kernel config file.  'N' should be the number of
	slip lines your plan to run.  E.g., "sl2" lets you run slip on
	two serial lines simultaneously.  For SunOS, use the line:

	    pseudo-device   slN init slattach

    (5) There are four config file options that set defaults for the
	slip driver:

	    SL_DOCOMPRESS	Lines will compress tcp packets by
				default. (This corresponds to
				IFF_LINK0.) (If this option is not set,
				compression won't be done and all
				packets will be compatible with
				RFC-1055.)

	    SL_ALLOWCOMPRESS	Lines will default to "auto-enable
				compression" (This corresponds to
				IFF_LINK1.) (See appendix B.2 in the
				RFC).

	    SL_NO_STATS		Disables various statistics in the
				driver (not a good idea).

	    SL_NOICMP		Outbound ICMP packets will be
				discarded. (This corresponds to
				IFF_LINK2.) This shouldn't have to be
				set, but some cretin pinging you can
				drive your throughput to zero.

	You shouldn't need to use any of these -- it's a better idea to
	have sliplogin set the link0, link1, and link2 parameters based
	on the configuration found in /etc/slip.hosts. See (2b) of the
	"NETWORK CONFIGURATION" section for more information.

    (6) You can use tcpdump to monitor the slip line if you install bpf
	in your kernel.  BPF is part of the tcpdump distribution, which
	is available via anonymous ftp from ftp.ee.lbl.gov.

    (7) Config, build, and boot the new kernel on both ends of the
	link. If you have access to a machine that already runs slip,
	it will be easier to bring up the new slip on one side with the
	old slip on the other.


NETWORK CONFIGURATION
---------------------

    (1) Create a "slip" group to be used by various programs in the package.

    (2) Build and install the applications:

	    sliplogin
	    slstats
	    slinfo
	    myetheraddr
	    tip

	Note that if you ignored the suggestion in "PRELIMINARIES (e)"
	to do a "make clean", you will want to at least remove
	tip/libacu/libacu.a before building tip. Also, you might want
	to make a backup copy of /usr/bin/tip before installing the
	slip version.

   (2a) Under SunOS 3 or 4.2BSD, you might first have to build and
	install libkvm (an emulation of the SunOS 4 library).

   (2b) SunOS 3, SunOS 4 and older versions of 4BSD do not support the
	-link0, -link1, and -link2 flags needed to control the slip
	interfaces. To handle these systems, build and install:

	    tools/ifconfig.

	Note that this version it does not support Sun's -a, -ad, and
	-au or auto-arp flags or the "+" netmask hacks. You'll either
	need to change your /etc/rc* files to not use these or else
	install the slip ifconfig as "ifconfig.slip" and hack the slip
	scripts to use it.

    (3) Install the sliplogin configuration files in /etc:

	    slip.hosts
	    slip.login
	    slip.logout

	"slip.hosts" will need to be edited for your site.  There is an
	example "slip.hosts" in the sliplogin directory.

	"slip.login" may need to have the line:

	    route set $R $L mtu 552 pipesize 2048 rtt 5 || exit 2

	Commented out since this is used to set some local,
	experimental parameters. But it's ok to leave it in under SunOS
	4 since the versions of route up through 4.1.2 exit with a
	successful status for unknown keywords...

	"slip.logout" should be okay as is.

	After you edit slip.hosts, do a "make install-conf" in the
	sliplogin directory.  "make install-man" will install the
	sliplogin man page. See this document for more information.

    (4) Do a `make install-conf' in the tip directory to install:

	    login.script.unix
	    login.script.netblazer
	
	in /etc. Remember to use one of these with the "ls" field in
	the /etc/remote slip entries. Add entries to /etc/remote for
	your setup. For example,

	    dial19200|Telebit attributes:\
		    :dv=/dev/cua0:br#19200:nt:fc:at=telebit:du:
	    UNIX|telebit|Telebit dial-out to another Unix system:\
		    :el=^U^C^R^O^D^S^Q@:ie=#%$:oe=^D:tc=dial19200:
	    dial-foo:\
		    :pn=dt5551212:tc=telebit:
	    foo|slip-foo:\
		    :st=slip:ls=/etc/login.script.unix S%h {passwd}:\
		    :cc=/etc/sliplogin Sfoo:tc=dial-foo:

	{passwd} is the password of the slip account on the remote
	side.  It is probably a good idea to only use this feature
	from the non-Internet side (i.e., at home).  Note that both
	login.script.unix and login.script.netblazer have the password
	lines commented out.  This means that by default, tip will
	prompt you for a password when it gets to that point in the
	login process. If you want tip to automatically supply a
	password, you'll need to edit login.script.unix or
	login.script.netblazer.

    (5) Make password entries for slip accounts on the server and
	client. See sliplogin man page for details. (Remember that Unix
	login names are limited to 8 characters so you should use
	hostnames that are 7 characters or less.)

	Make sure the accounts are in the slip group and that the uid
	is not root.  The login shell should be /etc/sliplogin.

    (6) Set up the ttys so you can dial in and out on the same line.
	Make the device entries:

	    # mv /dev/ttya /dev/ttyd0
	    # mknod /dev/cua0 c 12 128
	    # chmod 666 /dev/cua0

	Now edit /etc/ttytab.  Add the following line (we use Telebit
	T2500's and lock the speed at 19.2k):

	    ttyd0   "/usr/etc/getty D19200"         dialup          on secure

	If you use T1600's or t3000's, use 38.4k.

	You may need to make an entry in /etc/gettytab for D19200:

	    F|D19200|Fast-Dial-19200:\
		    :nx=D19200:fd@:tc=19200-baud:

	or perhaps:

	    H|D38400|Fast-Dial-38400:\
		    :nx=D38400:fc:fd@:tc=38400-baud:

    (7) At this point, you should be able to bring up the link by
	tipping to the remote host.  With the example above, all you
	should have to say is "tip foo", and give a password if
	necessary.

	Chances are that things won't work on the first try.  We have
	found debugging the configuration to be quite a headache.  Very
	simple problems are often quite time-consuming to find.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Dec 1992 04:22:55 GMT
From:      raney@teal.csn.org (Scott Raney)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: Public domain PPP for SCO 2.0??

larry@gator.rn.com (Larry Snyder) writes:

>jessea@u013.me.vp.com (Jesse W. Asher) writes:
 
>>Does anyone have SCO's PPP working with a Netblazer?
 
>Last I heard SCO shipped an older release of PPP with their
>product making non-compatible with other vendors..

Doesn't matter.  I just read (in another newsgroup) that DEC has a
patent on PPP, and is asking $5000 for a license.  That means no
public domain PPP, and a rapidly increasing reluctance to support it
from OEMs.  Stick with SLIP until something better comes along.

>-- 
>Larry Snyder                                    internet: larry@gator.rn.com
>keeper of the Gator                                  uucp: uunet!gator!larry
-- 
***********************************************************************
* Scott Raney  303-447-3936            Remember: the better you look, *
* raney@metacard.com                   the more you'll see -- Lidia   *
***********************************************************************

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 8 Dec 1992 10:50:43 EST
From:      <ADMN8684@RyeVm.Ryerson.Ca>
To:        comp.protocols.tcp-ip
Subject:   STII

I am interested in talking to any one who has implemented ST-II
in a UNIX kernel or who knows where I could get a UNIX kernel
with ST-II in it.
Thank you in advance.
West Suhanic, (416) 979-5000 ext 7420
E-Mail ADMN8684@RYEVM.RYERSON.CA

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 1992 06:04:52 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.protocols.ppp
Subject:   Re: Public domain PPP for SCO 2.0??

Scott Raney (raney@teal.csn.org) wrote:
: 
: Doesn't matter.  I just read (in another newsgroup) that DEC has a
: patent on PPP, and is asking $5000 for a license.  That means no
: public domain PPP, and a rapidly increasing reluctance to support it
: from OEMs.  Stick with SLIP until something better comes along.

This is *not* true.

DEC has a patent application outstanding for the negotiation of a 48 bit
checksum which might be used in one of the option negotiation phases.  It
is not an essential part of PPP; many implementations currently do not
use this little tiny algorithm in the way they work, and they work just
fine.

There is no indication that the 48 bit FCS will be accepted or standardized
on by the IETF - from my reading of the  mailing lists traffic that is
unlikely at this point.

There are free PPPs and there will continue to be free PPPs.  You will
also more likely buy PPPs as part of hardware you buy.

As to SLIP vs PPP, well, to be honest, the particlar serial line framing
protocol you use has very little to do with the ultimate satisfaction you
will have with your async internet connection.  Issues of robust compression,
redial on drop, filtering on redial, chat scripting, password handling, etc.
have much more to do with how good your dial-up Internet connection will be
than just how the bits go down the wire.  Put anohter way I'd rather have
a good SLIP implementation than a bad PPP implementation any day.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB
Msen sells dial-up IP (SLIP or PPP) connections, ask info@msen.com for details.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 92 06:16:25 GMT
From:      david@aim1.aztec.co.za (David Mason)
To:        comp.protocols.tcp-ip
Subject:   Re: Sending to Compuserve via Internet

chuck@npdiss1.StPaul.NCR.COM (Charles Rissmeyer) writes:

>Hi - Does anyone here know what addressing to use to send email to a
>user on Compuserve via the Internet?  I remember once seeing that Compuserve
>has a gateway to the internet, but I don't remember the addressing.
 
>Something like 75115,1366@compuserv.com perhaps?

I got this from compuserve a few days back (this is the wrong group,
but, hey, I'm only following up):
---------------------------------------------------------

>From compuserve.com!postmaster Thu Nov 19 20:48:05 1992
Date: 19 Nov 92 05:56:11 EST
From: Electronic Postmaster <POSTMASTER@CompuServe.COM>
To: <aim1!david@ucthpx.uct.ac.za>

Subject: Addressing CompuServe Mail users

A message you sent to a CompuServe Mail user is being returned
because it could not be delivered due to an incorrect address.  The
correct method of addressing CompuServe Mail users is outlined below.

There are two types of CompuServe Mail addresses.  They can be
reached from the Internet as follows:

a) Members of the CompuServe Information Service have an address
   (a.k.a. User ID) of the form "xxxxx,yyyy", such as "70000,11".
   To send mail to such an address from the Internet, change the
   comma to a period and attach "@CompuServe.com".  For instance:
        70000.11@CompuServe.com

b) Members of organizations with a private CompuServe Mail area have
   an address of the form "organization:name", such as "ABC:J.SMITH".
   To send mail to such an address from the Internet, send it to
   "name@organization.CompuServe.com".  For instance:
        J.SMITH@ABC.CompuServe.com

   A few organizations have addresses which also include a department
   in the form "organization:department:name", such as
   "ABC:ACCTG:JOHN".  To send mail to such an address from the 
   Internet, send to "name@department.organization.CompuServe.com". 
   For instance:
        JOHN@ACCTG.ABC.CompuServe.com


There are also a number of special destinations available to users of
CompuServe Mail which are NOT accessible from the Internet,
including: 

    Facsimile Delivery    (e.g. >FAX: )  
    Postal Delivery       (e.g. >POSTAL: )
    Telex Delivery        (e.g. >TLX: )
    MCI Mail Delivery     (e.g. >MCIMAIL: )

Finally, please realize that only CompuServe Mail users have access
to our member directory.  Since there is no mechanism for you to
obtain addresses directly from CompuServe Incorporated, you should
obtain this information from the individuals with whom you wish to
correspond.  Thank you.

    Coordially,

        The Electronic Postmaster
---------------------------------------------------------------
-- 
David Mason, Unix system support.
Aztec Information Management, Cape Town, South Africa.
#####
Status symbol of the 1990's ........ a job.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Dec 1992 08:22:44 GMT
From:      an1880@anon.penet.fi
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Different Subnets on one Ethernet segment?


Hi,

can anybody tell me, if I can have TWO different IP-subnets in ONE ethernet
segment???

Just for illustration:
net: 141.33.0.0
subnet1: 141.33.128.0
subnet2: 141.33.160.0

netmask: 255.255.224.0

If it is possible, how do I have to set the broadcast address?

Thanx in advance,

Andreas

*********************************************************************
* Andreas Priebe           * PHONE          +49 331 762 320         *
* Astrophysical Institute  * FAX            +49 331 762 309         *
* Potsdam, Germany         * EMAIL    apr@babel.aip.wtza-berlin.de  *
*********************************************************************
---------------------------------------------------------------------
To find out more about this service, send mail to help@anon.penet.fi.

name.of.news.group@anon.penet.fi	Anonymous posting to newsgroup
an9999@anon.penet.fi			Anonymous mail to anon user
user%host.domain@anon.penet.fi		Anonymous mail to known user
ping@anon.penet.fi			To test/allocate alias
nick@anon.penet.fi			To set nickname (in Subject:)
admin@anon.penet.fi			To reach administrator
an0@anon.penet.fi			To reach administrator anonymously

Or mail to anon@anon.penet.fi, with a "X-Anon-To:" header containing recipient.

Please note you _don't_ have to have an anon id to receive anonymous mail!

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Dec 92 08:37:40 GMT
From:      bpja@codex.com.au (Brett Adam)
To:        comp.protocols.tcp-ip
Subject:   Eudora - help getting remote Mac to work

I'm trying to get Eudora at home to dial the office via Comms Toolbox.
Eudora gets to the "telnet hostname" prompt and then simply waits. Eventually,  
it times out.

What am I doing wrong? Host is a Sun running SunOS 4.1.2.

Any help appreciated.

-- 
-------------------------------------------------------------------
Brett Adam                                      
Xedoc Software Development Pty. Ltd.           Melbourne, Australia
Phone    :                                           +61 3 696 2490

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 8 Dec 1992 10:22:39 +01
From:      Paul Bijnens <FFAAC09@cc1.kuleuven.ac.be>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

In article <1992Dec7.165101.2313@acc.com>, art@acc.com (Art Berggreen) says:
>
>Did you happen to use FTP in ASCII mode to perform your measurement?
>My Sparc 1 drops from approx. 600KB/s to approx 100KB/s when going
>from BINARY to ASCII FTPs (the end systems become CPU bound scanning
>the text stream).

I doubt scanning the text stream in ASCII mode is the culprit.  In
one of my connections, I have a this very strange problem that the
throughput in ASCII or BINARY depends on the window-size.
See table below.  The connection is made with a Motorola (running
Unix) connected to a PC 386SX (running DOS with PC/TCP) with a Compac
486 in between (running Vines).  The connection Motorola-Compac is an
Ethernet.  The connection Compac-PC is an ARCNET (2.5 Mb/s), running
the Vines protocol. The times are in seconds for a file of 167641 bytes
of text. Trafion all lines was very low while mesuring. (Get and put
from PC point of view, window and lowwindow varied on the PC).


 window    lowwindow       FTP-mode    get         put
 (bytes)     (bytes)                  (min-max seconds)
   1024          0         ASCII       58-59       5-6
                           BINARY      7-9         5-6

   1024        256         ASCII       7-9         5-6
                           BINARY      51-59       5-6

   1024        512         ASCII       56-61       5-7
                           BINARY      7-10        5-6

   1536        512         ASCII       7-9         5-6
                           BINARY      52-59       5-6


We can see in the table that changing the window size has an effect
on the performance of ASCII versus BINARY.
Has anyone a decent explanation for this behaviour?

One of the possible explanations is the use of "trailers".  Our
TCP/IP implementation does not use trailers (at least, the manual
is silent about is, and "strings ipconfig" does not show a string
containing "trail" or something).
Debugging information from the lower level protocols show no
communication problem (all error counts are 0).

(Yes, I know, the Vines network in between is a black box, where
everything is to blame for some people.  I do not believe them.)
--
Paul Bijnens             -- MS-DOS is the world's most widespread virus.
Linguistics dept., K. University Leuven, Belgium
Polleke@cc1.kuleuven.ac.be

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Dec 1992 18:35:42
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP simul- & broadcast

In article <id.XP1V.B11@ferranti.com> ihsan@ferranti.com (jaleel ihsan) writes:
    I have a few questions reguarding TCP simul- and broadcasts, if
    someone could please enlighten us:

TCP, as currently specified, connects one host with one other host.  It
does not do multi-point, and attempts to use multi-cast addresses will
result in a frustrating series of ECONNRESET errors.  People frequently
express interest in solving this problem with a new protocol, but I'm not
in a position to comment on feasibility or progress.

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


-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Dec 1992 18:44:55
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP info

In article <1992Nov18.170922.21993@ghost.dsi.unimi.it> mazzucch@ghost.dsi.unimi.it (massimo mazzucchi) writes:
    
    I use to communication UNIXtoDOS SLIP FTP Software PC/TCP version 1.16pl4
    
    - exist a new version and it is a commercila program or public domain?

A commercial, copyrighted program.  Your copy (or the one someone pirated
it from) was made in 1988, current production is v2.11 (with many changes).
    
    - for example if i have connect my pc with a serial port of 
         a modem in which way i can use command ftp correctly?( there
         are 2 file *.sys that i have place in Config.sys)

1.16 included an FTP.EXE, the SLIP version uses the PC's serial port.
The .SYS files must be configured with the PC's IP address, baud rate, etc.
    
     - there 2 file IPCONFIG and IFCONFIG - in which way i must use them?

This is explained by the Installation Guide & the IPCONFIG & IFCONFIG
sections of the Command Reference.  1.16 manuals are out of print.

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


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Dec 1992 18:49:37
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over Token-Ring

In article <1992Nov17.183545.25323@tandem.com> ellingsen_jim@Tandem.COM (Jim Ellingsen) writes:

    Do most TCP/IP over token-ring implementations support source routing?  

3 or 4 years ago, source routing support was not universal.  Now, I'm not
aware of any major implementations that don't do it.

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


-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Dec 1992 18:55:05
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP security labels

In article <1992Nov17.154727.21216@hplb.hpl.hp.com> paola@hplb.hpl.hp.com (paola fulchignoni) writes:

    Could anyone give me more details about RFC 1108 (IETF document in
    which security labels handling in IP packets is explained) and/or how
    to find it? 

RFC 1108 is available from any RFC archive site (nic.ddn.mil is one,
nnsc.nsf.net is another).  Its issue was delayed quite a while by
evolution of the protocols due to implementation experience, but it
does completely obsolete RFC 1038.  Our current version of PC/TCP for
DOS (v2.1) conforms to it, but I'm not aware of anyone specifically
testing interoperability with anything else.

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


-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Dec 1992 14:05:34 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: INFO on GOPHER NEEDED!

In article <TWANG.92Dec7185018@thor.albany.edu> twang@csc.albany.edu (Teddy Wang) writes:
>I really didn't know where to ask this information so I posted it at a 
>bunch of groups I don't frequent.  Please e-mail me any responses.

  gophers are discussed in comp.infosystems.gopher rather than
	in comp.protocols.tcp-ip

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 92 14:06:38 GMT
From:      barrett@daisy.ee.und.ac.za (Alan P Barrett)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: The 'ANY' query request vs non-authoritative DNS servers

In article <PST.92Dec7214755@cider.cisco.com>,
pst@cisco.com (Paul Traina) writes:
> I'm writing some DNS client code to support the new NSAP additions,
> and I have some generic questions I'm hoping someone can help out on.

New NSAP additions?  Please tell me more.

> (a) Is they "ANY" query type documented anywhere?  I didn't notice any
>     reference in either RFC's 1034 or 1035.  Is this really a legal query?

RFC 1035 section 3.2.3 defines QTYPE=*, whicy is what people mean
when they say QTYPE=ANY.  Similarly, section 3.2.5 defines QCLASS=*.
Section 4.1.2 talks about "some more general codes which can match more
than one type of RR", and QTYPE=* is clearly one of these.  I expect
that more careful reading of RFC 1035 will turn up more examples.

> (b) If a cacheing DNS has done a query for all A records of a
>     particular host,  and it receives a query for ANY,  should/will it
>     only return the A records it has cached as a non-authoritative
>     answer?

I am too lazy to hunt down the relevant chapter and verse right now,
but this is my understanding of what should happen on receipt of a query
with QCLASS=<something other than *> and QTYPE=*:

    If the server is authoritative for the given domain and class,
    it should return all the records as an authoritative answer.

    Otherwise, if it has anything cached, it should return that as a
    non-authoritative answer.

    Otherwise, if recursion is both available and desired, then it should
    recurse to a better server, and relay its answer.

    Otherwise, it should return a non-authoritative empty answer.

Similar things happen with QCLASS=*, except that authoritative answers
are almost impossible, and I am not sure how recursion would work.

> Basicly, I'd like to send out one query for a host and get back any A
> or NSAP records associated with that host,  however I'm concerned that
> (a) not all DNS systems support query types of ANY

Any DNS implementation that cannot handle queries with QTYPE=* is broken
even worse that the common Unix implementations.

> and (b) cacheing nameservers that happen to have an A record already
> in the cache will simply respond with the information they have caches,
> as opposed to the full query.

Yes, they will do this.  QTYPE=* means "return any info that you happen
to have available", it does not mean "return all info that exists".

I recommend that you do two separate queries, one for the A records and one
for the experimental NSAP records.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Dec 1992 15:33:07 GMT
From:      ajj@beta.lanl.gov (Andrew J. Johnson)
To:        comp.protocols.tcp-ip
Subject:   DNS That Supports VAX Clusters?

Our company is in the middle of transition from a (DEC - LAT) terminal
server network, where our personal computers are attached to DECServers
and emulate VT100 terminals, to a TCP/IP-based network, where the PC's
are directly on the LAN as TCP/IP peers. One problem has come up in
accessing VAX clusters (and other host services that have multiple IP
addresses - for example an IBM mainframe with two channel attached 3172's
providing access to the LAN). With terminal servers, users access
specific nodes on a network by requesting a generic cluster name and
being connected to the cluster member (VAX) that happens to have the most
CPU resources available. We can't do this with DNS and have implemented
clumsy workarounds based on statically partitioning user groups and
assigning to specific VAX nodes.

My question is has anyone modified DNS server code to account for VAX
clusters or one service with multiple IP addresses? At the very least I
would like a service that roundrobins, e.g with a 3 node service VAX1,
VAX2, VAX3 with genric service name of VAX, first request for IP address
of VAX get IP address of VAX1, second gets VAX2, third gets VAX3, fourth
gets VAX1 and so on. One wrinkle would have the DNS node PING the service
node to see that it is alive before returning its address to the client.
A really nice wrinkle would have the DNS node monitor LAT service
multicasts from VAX Cluster members to get latest service ratings and
hand out IP addresses based on least loaded. 

-- 
                                       Andy Johnson
                                       Westinghouse Savannah River Company
                                       ajj@lanl.gov
                                       (803) 644-1493

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Dec 1992 15:53:00 GMT
From:      adelman@tgv.com (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS That Supports VAX Clusters?

In article <1992Dec8.153307.290@newshost.lanl.gov>, ajj@beta.lanl.gov (Andrew J. Johnson) writes...
>Our company is in the middle of transition from a (DEC - LAT) terminal
>server network, where our personal computers are attached to DECServers
>and emulate VT100 terminals, to a TCP/IP-based network, where the PC's
>are directly on the LAN as TCP/IP peers. One problem has come up in
>accessing VAX clusters (and other host services that have multiple IP
>addresses - for example an IBM mainframe with two channel attached 3172's
>providing access to the LAN). With terminal servers, users access
>specific nodes on a network by requesting a generic cluster name and
>being connected to the cluster member (VAX) that happens to have the most
>CPU resources available. We can't do this with DNS and have implemented
>clumsy workarounds based on statically partitioning user groups and
>assigning to specific VAX nodes.
>
>My question is has anyone modified DNS server code to account for VAX
>clusters or one service with multiple IP addresses? At the very least I
>would like a service that roundrobins, e.g with a 3 node service VAX1,
>VAX2, VAX3 with genric service name of VAX, first request for IP address
>of VAX get IP address of VAX1, second gets VAX2, third gets VAX3, fourth
>gets VAX1 and so on. One wrinkle would have the DNS node PING the service
>node to see that it is alive before returning its address to the client.
>A really nice wrinkle would have the DNS node monitor LAT service
>multicasts from VAX Cluster members to get latest service ratings and
>hand out IP addresses based on least loaded.

    In the next release of MultiNet (V3.2) we've done just this.  You
can delegate authority for the cluster wide name to the nameservers
running on your VAXcluster.  They will co-ordinate among themselves to
answer the service requests with the IP address of the least-loaded
machine and with a short TTL so the data isn't cached for long.

    If you're interested in testing this prior to the January release
of MultiNet V3.2, let me know and I'll get you a field-test copy.

							    Ken

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 92 16:39:15 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Different Subnets on one Ethernet segment?

In article <1992Dec8.091111.28843@penet.fi> an1880@anon.penet.fi writes:
>
>Hi,
>
>can anybody tell me, if I can have TWO different IP-subnets in ONE ethernet
>segment???
>
>Just for illustration:
>net: 141.33.0.0
>subnet1: 141.33.128.0
>subnet2: 141.33.160.0
>
>netmask: 255.255.224.0
>
>If it is possible, how do I have to set the broadcast address?

Sure, having multiple subnets on one wire is often used in many site's
subnetting strategy.  Most routers can deal with assigning multiple
subnets to their interfaces.  The biggest problem though, is that most
host TCP/IP implementations only support one IP address on a physical
interface, and thus they must be defined on only one subnet.  This
means that traffic between subnets may have to be sent via a router.
(BSD Unix derived implementations usually can use a direct subnet route
to avoid the extra hop)

The hosts then have their broadcasts set appropriate for the subnet
they are configured for.  The configuration of the router depends on
the vendor.

>Thanx in advance,
>
>Andreas

Art

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Dec 1992 16:57:45 GMT
From:      dbasinge@ucs.indiana.edu (D. Michael Basinger)
To:        comp.protocols.tcp-ip
Subject:   VT240 emulator /w Regis graphics

I'm looking for a VT240 emulator that can understand REgis graphics
on a IBM PC, NeXT, or Macintosh. It neededs to work on a ethernet 
network.

Mike
--
D. Michael Basinger:    Not speaking for I.U. or the School of HPER
Computer Specialist     dbasinge@bronze.ucs.indiana.edu
School of HPER          dbasinge@arapahoe.ucs.indiana.edu (NeXT Mail)
Indiana University      Phone: (812) 855-1562   Fax: (812) 855-4983

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 92 17:05:09 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

In article <92343.102239FFAAC09@cc1.kuleuven.ac.be> Paul Bijnens <FFAAC09@cc1.kuleuven.ac.be> writes:
>I doubt scanning the text stream in ASCII mode is the culprit.  In
>one of my connections, I have a this very strange problem that the
>throughput in ASCII or BINARY depends on the window-size.
>See table below.  The connection is made with a Motorola (running
>Unix) connected to a PC 386SX (running DOS with PC/TCP) with a Compac
>486 in between (running Vines).  The connection Motorola-Compac is an
>Ethernet.  The connection Compac-PC is an ARCNET (2.5 Mb/s), running
>the Vines protocol. The times are in seconds for a file of 167641 bytes
>of text. Trafion all lines was very low while mesuring. (Get and put
>from PC point of view, window and lowwindow varied on the PC).
>
>
> window    lowwindow       FTP-mode    get         put
> (bytes)     (bytes)                  (min-max seconds)
>   1024          0         ASCII       58-59       5-6
>                           BINARY      7-9         5-6
>
>   1024        256         ASCII       7-9         5-6
>                           BINARY      51-59       5-6
>
>   1024        512         ASCII       56-61       5-7
>                           BINARY      7-10        5-6
>
>   1536        512         ASCII       7-9         5-6
>                           BINARY      52-59       5-6
>
>
>We can see in the table that changing the window size has an effect
>on the performance of ASCII versus BINARY.
>Has anyone a decent explanation for this behaviour?

For TCP, those are TINY windows (if those numbers really are the TCP
window).  I believe SUN-OS by default sets the TCP window for the data
connection to 24K.  I would expect such a small window to make TCP
a "send one and wait" protocol, with no pipelining.  Also, what are
your disk I/O subsystems capable of?  When FTPing to DOS systems, we
find things are usually disk limited.  Also, I would expect much more
consistancy between ASCII and BINARY times.  Any way of checking TCP
statistics for retransmissions?

>One of the possible explanations is the use of "trailers".  Our
>TCP/IP implementation does not use trailers (at least, the manual
>is silent about is, and "strings ipconfig" does not show a string
>containing "trail" or something).

Trailers should not even be enabled in your environment.  I doubt
that the hosts would negotiate their use though.

>Debugging information from the lower level protocols show no
>communication problem (all error counts are 0).
>
>(Yes, I know, the Vines network in between is a black box, where
>everything is to blame for some people.  I do not believe them.)

Is the Compac encapsulating the IP packets in Vines packets across the
ARCNET?

>Paul Bijnens             -- MS-DOS is the world's most widespread virus.
>Linguistics dept., K. University Leuven, Belgium
>Polleke@cc1.kuleuven.ac.be

Art

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 1992 17:34:09 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: INFO on GOPHER NEEDED!

Teddy Wang (twang@csc.albany.edu) wrote:
: 
: My university (SUNY Albany) is looking to setup a gopher (clients and
: servers) on our UNIX Cluster.  I need any infomation possible on 
: the HOW-TOs of such a task.  A FAQ would be stupendously helpful, as
: well as configurations on already setup units.  

See 'comp.infosystems.gopher', or if you don't get it at your site, 
start with the software available for anonymous ftp from
	boombox.micro.umn.edu:/pub/gopher

There is no RFC that describes gopher, but there is a protocol document
in this archive.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 1992 17:36:58 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS That Supports VAX Clusters?

Andrew J. Johnson (ajj@beta.lanl.gov) wrote:
: 
: My question is has anyone modified DNS server code to account for VAX
: clusters or one service with multiple IP addresses? 

The U of Michigan version of 'bind' has this, using a special class
of 'shuffle A' records to return a random host for each query.  I
believe the code is on terminator.rs.itd.umich.edu, but if you can't
find it there queries to 'hostmaster@umich.edu' should turn it up.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB


-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 92 18:35:58 GMT
From:      carl@asi.com (Carl Ellis)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   looking for PC based router software


Does anyone know of a software package that runs on PC's
(286 or better) that provides good routing capabilities and
supports SLIP and ethernet?  

I've had suggestions to look at "pcroute" or some of the PD
or inexpensive UNIX solutions.  However, none of these
seem to support port or src/dst filtering.

Commericial packages are OK.

Please respond via email.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
 Carl Ellis                                      carl@asi.com
 Software Engineer, Adaptive Solutions, Inc.     uunet!adaptive!carl
 1400 NW Compton, Suite 340                      VOICE (503) 690-1236

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 92 22:07:52 GMT
From:      hotz@isi.edu (Steve Hotz)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: The 'ANY' query request vs non-authoritative DNS servers

Hi,

>> Is they "ANY" query type documented anywhere?  I didn't notice any
>> reference in either RFC's 1034 or 1035. Is this really a legal
>> query?

The RFCs refer to the string "*" rather than "any" to mean records
of all/any QTYPE.  RFC-1034 section 3.7.1 [page 17] mentions "*",
and RFC-1035 section 3.2.3 defines 255 as a request for "*" (all RRs).

Also, issues similar to the questions you're asking are mentioned
in RFC-1035 section 3.6 [page 24] and in the example in section
6.2.2 of RFC-1034.

>> If a cacheing DNS has done a query for all A records of a
>> particular host,  and it receives a query for ANY,  should/will
>> it only return the A records it has cached as a non-authoritative
>> answer?

Yes, it should (and in all implementations i've seen will) do so.
The default desired behavior is to assume the cache is good enough,
so to eliminate extra recursive queries.  However, this still allows
a resolver/application to "go the extra mile" and obtain authoritative
answers if required.  Lower-cost default-case behavior.

>> Basicly, I'd like to send out one query for a host and get back any
>> A or NSAP records associated with that host,  however I'm concerned
>> that (a) not all DNS systems support query types of ANY,

Probably not something to be concerned about.

>> and (b) cacheing nameservers that happen to have an A record
>> already in the cache will simply respond with the information
>> they have caches, as opposed to the full query.

Definitely something to be worried about -- you simply must make two
seperate queries.

An alternative is to do something similar to what was done
with mail-exchange records.  Rather than having two types of RRs
for mail (MD and MF indicating different preference), we now have
a single RR Qtype with explicit preferences (that are retrieved
and cached "atomicaly").  So, the analog for addresses would be
a "generic address" RR, which explicitly gives the type, e.g.

isi.edu.         MX       0 isi.edu.
isi.edu.         MX      10 quark.ISI.EDU.

venera.isi.edu   GA      IP 128.9.0.32
venera.isi.edu   GA    NSAP XX:YY:ZZ:AA00:0032

Two queries is probably the path of least resistance at this point,
although introducing something like a GA RR might be a cleaner
solution in the long run.

xxoo,
	steve

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Dec 92 23:51:35 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: IP security labels

In article <921208185505@cream.ftp.com> jbvb@ftp.com writes:
>
> [some text deleted ...]
>does completely obsolete RFC 1038.  Our current version of PC/TCP for
>DOS (v2.1) conforms to it, but I'm not aware of anyone specifically
>testing interoperability with anything else.
>

There is also an effort to extend RFC 1108 to include compartented mode
labels.  This effort is called DNSIX, and is almost complete.  An
industry consortium called MAXSIX is developing common software to
implement this, so (hopefully) interoperability will not be a great
problem.

OBTW, our (Network Systems/Vitalink) routers will actually do packet 
filtering based on RFC 1108 (and RFC 1038, too, if you want to bother),
and can insert or remove labels for hosts that don't understand this.

- Ted

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

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 92 01:58:44 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   Ftp bug.

[ Article crossposted from ncr.sys.unix ]
[ Author was Bhyravabho Rama ]
[ Posted on 9 Dec 92 01:55:01 GMT ]

Recently, while trying ftp across two NCR 3000 machines, I came across a  
strange bug in FTP.  It seems if I try to login as a user that does not have
a password, FTP prompts for the password, and when I hit any key or the 
'enter', It assumes that is the password I typed, and since the account
does not have a password the login fails.  Could anybody tell me if this
has been fixed in a later release or not.  If so which release? 

Also, I am running Unix V.4 on these machines.  Has anybody else run into
this problem yet?  

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 92 01:58:52 GMT
From:      alech@hpindda.cup.hp.com (Alec Henderson)
To:        comp.protocols.tcp-ip
Subject:   Need MIME Information

Can anyone help me find information on MIME?

Which RFC(s) is it defined in?
Are there any other sources of information (descriptive articles, etc.)?

Thanks!

Regards,
Alec Henderson

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

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Dec 1992 03:10:17 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
Subject:   Re: The 'ANY' query request vs non-authoritative DNS servers

|> >> Is they "ANY" query type documented anywhere?  I didn't notice any
|> >> reference in either RFC's 1034 or 1035. Is this really a legal
|> >> query?
|> >> ....
|> >> and (b) cacheing nameservers that happen to have an A record
|> >> already in the cache will simply respond with the information
|> >> they have caches, as opposed to the full query.
|> 
|> Definitely something to be worried about -- you simply must make two
|> seperate queries.

You should probably also be prepared to handle the case where the QTYPE=*
result doesn't fit in a single DNS UDP reply. This is a very real possibility
if a particular domain name has a lot of crud associated with it (e.g. free-
field TEXT records, long MX forwarder names, multiple long NSAPs, etc.)

	--Vince

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Dec 1992 04:05:40 GMT
From:      seetog@cheops.qld.tne.oz.au (Paul O'Keeffe)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet addresses vendor list

seetog@cheops.qld.tne.oz.au (Paul O'Keeffe) writes:

>I remember seeing a list of hardware vendors and their corresponding
>Ethernet addresses.  Does anyone know where I can find such a list?

It seems that RFC1340 is what I was after.

Thanks again to all those who replied,

Paul O'Keeffe.
(seetog@cheops.qld.tne.oz.au)

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Dec 1992 12:43:46
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: NSFNet goes to hell..

In article <avalon.722651018@coombs> avalon@coombs.anu.edu.au (Darren Reed) writes:

    ... why then, does a route change always spell death for most TCP
    connections that are running over the changing route ?

Only if you're using certain 4bsd-derived TCPs.
    
    My guess is that somewhere, "unreachable" packets are being sent
    back to hosts by some router while the route is changing - does
    anyone have any evidence of the what goes on during a route change
    or why connections always seem to die ?

When the routing changes, it takes a certain time to become stable.
During this period essentially anything can happen to a packet.  4bsd's
TCP was originally completely ignorant of ICMP errors, and when they
changed it, they made it far too sensitive, such that any error cause
the connection to be instantly dropped.  Given that routing that stabilizes
instantly can't be done with low-traffic routing protocols, it would be
much better to tell your TCP/IP vendor to conform to Host Requirements
(RFC 1122, section 4.2.3.9).

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


-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Dec 1992 12:53:47
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs. Telnet

In article <1fevghINNgtr@uniwa.uwa.edu.au> comrade@uniwa.uwa.edu.au (Peter Cooper) writes:

    .... I have been led to believe that rlogin is kinder to the network (???)

Rlogin network traffic is essentially the same as Telnet.  The only
difference is that that because Rlogin doesn't have in-band commands like
Telnet's IAC xxx, you can write a Unix rlogind which consumes less cycles
than an equivalent telnetd.

Note that the "log in without password" feature of Rlogin and Rsh depends
on a very questionable concept: that the source IP address of a TCP
connection proves that it can be "trusted".  This ceased to be true in
1984 or so, when the first PC TCP/IP implementation appeared, and is
completely obsolete in these days of cheap personal Unix workstations.

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


-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Dec 92 17:06:15 GMT
From:      lriffe@isis.unm.edu (Larry Riffe II)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP to ATM draft standard

   I was reading the November 30th issue of COMMUNICATIONS WEEK the other
   day and saw an article about the ietf plans to release a proposed 
   standard on the interconnection of TCP/IP networks and ATM networks.
   The article mentioned that "a document containing the proposed standard's
   specifications will be released next month."

   I was wondering if anybody knew if the document has been released yet,
   and if so, how I could get a copy.  If it hasn't been released yet, 
   does anybody know when it will be.

                                            Thanks,
                                                      Larry G. Riffe II
                                                      lriffe@ariel.unm.edu

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 92 17:56:43 GMT
From:      seifert@netcom.com (Rich Seifert)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: Hex nubers for protocols

In article <1g0ragINNceg@terminator.rs.itd.umich.edu>, royboy@css.itd.umich.edu (Roy Hockett) writes:
> This is probably is a FAQ question.  Is there a list of protocols and
> their corresponding Hex number?
> 

RFC 1340 contains the "Assigned Numbers List", which includes the
protocol type assignments for most protocols.



-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Dec 92 19:21:52 GMT
From:      tsv@elvis.msk.su (Igor P. Tsvetkovsky)
To:        comp.windows.x,comp.protocols.tcp-ip,comp.sys.sun.wanted
Subject:   Sun Multicast Realization ?


        In my work I need MULTICASTING. Does anybody know 
about MULTICAST realizations for SunOS 4.1.* ?
        Where can I get information about it?

        Thanks!

Igor Tsvetkovsky
ELVIS corp.

World  :  tsv@elvis.sovusa.com
ExUSSR :  tsv@elvis.msk.su




-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 1992 20:47:12 GMT
From:      geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: Public domain PPP for SCO 2.0??

In article <raney.723788575@teal> raney@teal.csn.org (Scott Raney) writes:
#>Doesn't matter.  I just read (in another newsgroup) that DEC has a
#>patent on PPP, and is asking $5000 for a license.  That means no
#>public domain PPP, and a rapidly increasing reluctance to support it
#>from OEMs.  Stick with SLIP until something better comes along.

Skimming comp.protocols.ppp can be misleading. DEC is claiming
a patent on a 48-bit CRC algorithm. The patent is questionable,
IMHO, but in any case the 48-bit CRC is an optional element
in PPP, and the patent will ensure that it remains a very
infrequently exercised option.... PPP is alive and well.

(And no. I don't have a date for a PC-NFS PPP :-(

Geoff
--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
ADMINISTRIVIA==========ADMINISTRIVIA=====ADMINISTRIVIA==========ADMINISTRIVIA
New address: SunSelect, 2 Elizabeth Drive, Chelmsford, MA 01824-4195
New numbers: Phone: 508-442-0317   FAX: 508-250-5068   

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 92 21:32:53 GMT
From:      paul@alantec.com (G. Paul Ziemba)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp bug.

brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama) writes:

> the [ftp] login fails [for an unpassworded account].
> Could anybody tell me if this has been fixed...

Sounds like a security feature to me :-)

 ~!paul
-- 
Paul Ziemba  paul@alantec.com	alantec!paul  408.955.9000 x227

"The first TV I ever owned...I threw from a third story window at a burglar"
 - sjackson@parc.xerox.com

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Dec 1992 23:38:19 GMT
From:      bryan@uhura1.uucp (Bryan Curnutt)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   how to find rexec client?

I'd like to have a program 'hostfrom' on a UNIX machine (SunOS 4.X,
HP-UX 8.X/9.X, AIX 3.X, Ultrix 4.X, DG/UX 5.4X) that prints the name
of the host from which you're connected, if you're running a command
remotely.  For example, if I rlogin from host1 to host2, then run
'hostfrom' on host2, I want it to print "host1".  If I run
'rsh host2 hostfrom' on host1, I want it to print "host1".  If I
run a program on host1 that uses rexec() to run a 'hostfrom' on host2,
I want it to print "host1".  One of my main reasons for wanting
this is that I have a DOS program (in executable form, not source)
that uses the rexec protocol to run a command on a UNIX machine, and
I can specify the command, but want to make the PC host name part of
the command, as in "xterm -display `hostfrom`:0".

I'm currently pretty ignorant of sockets and network programming.
I'm presuming that there's a reasonably straightforward way of
doing this, which may not be a good presumption.  Can anyone
point me in the right direction?
-- 
Bryan Curnutt                                  Stoner Associates, Inc.
bryan%uhura1@uunet.uu.net       (713)626-9568 voice  (713)622-7832 fax

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 92 00:25:46 GMT
From:      ohayon@jcpltyo.jcpl.co.jp (Tsiel Ohayon)
To:        comp.windows.x.motif,comp.windows.x,comp.protocols.tcp-ip,comp.windows.x.intrinsics
Subject:   1 Application / 2 Machines



Hi out there,

I'm not a big reader of these newsgroups so please e-mail your answers to
me.

This is the question.

I would like to run 2 applications off two distant (same room) machines.
The first application would enable a user to enter an order of some sort
whereas the second application would recieve the order and display it
on the screen. Is there any way X/Motif can handle this.

Maybe a solution would be to have 1 application running on 2 machines.

We are using Sun Sparc 2, Sun Os 4.1.1, Motif release 4 (I think)

Thanks in advance


Tsiel
----8<--------------------------------------------------------------->8------
Tsiel:ohayon@jcpl.co.jp	   | If you do not receive this E-mail, please let me
Employer may not have same | know as soon as possible, if possible.
opinions, if any !         | Two percent of zero is almost nothing.

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 1992 02:49:31 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Concentrator Imposing IP addr?

Does anyone know of a 10base-T concentrator (or perhaps a multiport
router) that can impose an IP addr on each port. The idea is to be able
to be sure that IP addrs can be mapped back to specific nodes.

Something a little weaker would be a router that could impose an
ethernet addr to IP addr mapping.


---
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611



-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 1992 03:38:33 GMT
From:      shlam@ie.cuhk.hk (Alan S H Lam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   slip connection between DEC machine and the PC/TCP software on pc


Does anyone successfully make the slip connection between the 
"slattach" on DEC 5125 machine and the slip of PC/TCP 2.1 software 
on 486 pc through modem line?

I have rebuilt the kernel and configured the /etc/sliphosts on my
DEC machine. I have also configured the pctcp.ini file on my pc.
However, I still cannot make it. The telephone line hangup somehow.
I think I may miss some steps in the configuration on both sides 
or miss some actions while making the connection.

If anyone has successfully made the  slip connection between DEC 
workstation and the PC/TCP on pc , could you please send me a e-mail 
and share your experience with me? I will very very appreciate it. 
Thanks.


--
Alan S. H. Lam
Department of Information Engineering, CUHK, Hong Kong
E-mail: shlam@ie.cuhk.hk 
Tel: (852) 609 7975 Fax: (852) 603 5032

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 1992 03:48:02 GMT
From:      bern@Uni-Trier.DE (Jochen Bern)
To:        comp.protocols.tcp-ip
Subject:   Need Advice on special IP #

I hope that this goes into the right Newsgroup. I've got a Problem
concerned with IP Numbers and a Computer which is not at a fixed
Location.

I will soon create a "biheaded" Computer. As long as it is booted
from our NIS Domain Network, it will be a normal Client. In Addi-
tion, it has got its own Hard Disk. We intend to download newly
developed Software onto this Disk, take the Computer anywhere,
boot it from the Disk and run Demos on it without having to send
the Software around. Network Access ain't REALLY necessary, but
it would be fine. Question: Which IP # to use? I have to decide
this in Advance because SUNs get their own IP # hardcoded into
some Boot Bozo, so changing /etc/hosts ain't enough.

Giving it another IP # from our normal Domain is undesirable be-
cause in Order to access the Visitor, the local Networkers would
have to tear down the Routing to our Domain; This would keep us
from fetching a forgotten File, send Mail to ourselves etc.. I
thought that there might be some "escape Network", 127.x.x.x or
something of this Kind, which is ALWAYS interpreted to be Part
of the local Subnet no Matter which Number would be "correct".
Unfortunately, this seems not to exist; Some Hardware even de-
stroys Packets directed to such an Address. I could just go on
and usurpate a random or insignificant Network, but I'ld rather
like to conform to whatever Consensus might be found. Anybody
sees a Chance of having a Class C Network allotted for this spe-
cial Purpose? (I sent a Request for Advice to SRI-NIC, but there
hasn't been any Answer for a Month or two.)

Please note: Followup-to: poster

Thanks for your Help,
								J. Bern
-- 
 /  \  I hate NN rejecting .sigs >4 lines. Even though *I* set up this one. /\
/ J. \ EMail: bern@[TI.]Uni-Trier.DE / ham: DD0KZ  / More Infos on me from /  \
\Bern/ X.400 Mail: S=BERN;P=Uni-Trier;A=dbp;C=de  /   X.400 Directory, see \  /
 \  /  Zurmaiener Str. 98-100, D-W-5500 Trier    /     X.29 # 45050230303.  \/

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 92 10:57:02 GMT
From:      steve@terminus.ericsson.se (Steve Reynolds)
To:        comp.protocols.tcp-ip
Subject:   why is rfc1356 mtu 1600 bytes?



I have been checking our conformance to rfc1356, and the MTU has been increased
to 1600 bytes.

This is fair enough , but why 1600?

Is this a lowest common denominator for existing technologies?


thanks in advance

steve


---

---------------------------------------------------
| Steve Reynolds                                  |
| Ericsson-CAMTEC                                 |
| Leicester                                       |
| UK                                              |
| TEL:    +44 533 537534                          |
| EMAIL:  steve@terminus.ericsson.se              |
 ---------------------------------------------------

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 92 22:32:42 -0600
From:      kraai4712@iscsvax.uni.edu
To:        comp.protocols.tcp-ip
Subject:   FAQ?

<Boy ducks head behind arms> "FAQ?  Pointers, please?" <slinks away>

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 1992 12:59:06 GMT
From:      cpcahil@vti.com (Conor P. Cahill)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: Public domain PPP for SCO 2.0??

ronf@panther3.panther.mot.com (Ron Feigen) writes:

>Can you patent a protocol anyway????


That is what Hayes has done with the <min_time>+++<min_time> escape
sequence for modems, so I guess you can.

-- 
*** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***

Conor P. Cahill              (703)430-9247            cpcahil@virtech.vti.com
Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 20166 

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 1992 13:47:13 GMT
From:      mobrien@telesciences.com (Mark W O'Brien)
To:        comp.protocols.tcp-ip
Subject:   Summary of responses: tcp source location

>       Are the sample sources available from the Comer or Stevens books on
>       tcp/ip - UNIX Network programming?
>

Thanks to all who responded. I successfully ftp'd the Stevens source
from:

	site:         ftp.uu.net

	directory:    /published/books

	file:         stevens.netprog.tar.Z

-- 
 _______________________________________________________________________
								
                       "I never liked Star Trek"
 _______________________________________________________________________

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 1992 17:21:12 GMT
From:      szymon@uci.agh.edu.pl (Szymon Sokol)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Different Subnets on one Ethernet segment?

In article <ByzHy2.14F@wm.estec.esa.nl> Dave Stafford writes:
>From: Dave Stafford
>Subject: Re: Different Subnets on one Ethernet segment?
>Date: Wed, 9 Dec 1992 08:51:37 GMT
>In article <1992Dec8.163915.3076@acc.com> art@acc.com (Art Berggreen) writes:
>>In article <1992Dec8.091111.28843@penet.fi> an1880@anon.penet.fi writes:
>>>
>>>If it is possible, how do I have to set the broadcast address?
>>
>>Sure, having multiple subnets on one wire is often used in many site's
>>subnetting strategy.  Most routers can deal with assigning multiple
>>subnets to their interfaces.  The biggest problem though, is that most
>>host TCP/IP implementations only support one IP address on a physical
>>interface, and thus they must be defined on only one subnet.  This
>>means that traffic between subnets may have to be sent via a router.
>
>Not necessarily. If you set the subnet mask on the host to be
>255.255.0.0, it will assume all subnets of the class B network
>are on the same network, and ARP. Most routers support proxy ARP
>and will forward packets to other subnets, whilst hosts on the
>same wire will respond to the ARP directly.

This is risky. We did it and then decided to change the netmasks to
the correct 255.255.255.0 (we use 8-bit subnet field). If you want to
know why, read the FAQ entry on "broadcast storms".


                           Szymon Sokol
U     U  M     M  M     M  Network Manager
U     U  MM   MM  MM   MM  University of Mining and Metallurgy, Computer Center
U     U  M M M M  M M M M  ave. Mickiewicza 30
U     U  M  M  M  M  M  M  30-059 Krakow, POLAND
 UUUUU   M     M  M     M  TEL. +48 12 338100 EXT. 2885    FAX +48 12 338907

 "The reward of a thing well done is to have done it"  -- Emerson

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 92 17:31:16 GMT
From:      srl@terminus.ericsson.se (Steve Langstaff)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP for TCP/IP and WIN/TCP

INTERNETWORKING WITH TCP/IP

Principles, Protocols, and Architecture
                     ^^^^^(sic)

By:

DOUGLAS COMER, Prentice Hall International.

ISBN:	0-13-470188-7

This is (almost) a Bible.
                 ^^?

- Although the stories aren't quite so old.

---

 -----------------------------------
| Steve Langstaff - Ericsson CAMTEC |
 -----------------------------------

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 1992 19:06:00 GMT
From:      act@sun.ipl.rpi.edu (just another programmer)
To:        comp.windows.x,comp.windows.ms,comp.protocols.tcp-ip
Subject:   TCP/IP and X under MS Windows 3.1?

I am very curious about people's experiences running TCP/IP software
under Win 3.1.  I am contemplating putting an Xserver onto a machine running 
Win 3.1 and connecting it to a Unix host to run Unix apps over the net.

So  what kind of experiences have people had and/or recommendations.  I've only
just begun tis so if there is any recommended reading that would also be
appreciated.

Thanks
Grant


-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 1992 21:25:51 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.comp.protocols.ppp
Subject:   Re: Public domain PPP for SCO 2.0??

In article <1992Dec9.165234.21241@panther.mot.com> ronf@panther3.panther.mot.com (Ron Feigen) writes:
   In article <raney.723788575@teal> raney@teal.csn.org (Scott Raney) writes:
      I just read (in another newsgroup) that DEC has a patent on PPP,
      and is asking $5000 for a license.  That means no public domain
      PPP, and a rapidly increasing reluctance to support it from
      OEMs.

You misunderstood what you read.  DEC has applied for a patent on one
tiny corner of PPP.  Their actions will almost certainly not affect
anyone else in the PPP-using or -vending community, whether they're
using free or commercial implementations.

      Stick with SLIP until something better comes along.

It already has, of course.

   You can also get the PD version from the U of Ohio via FTP.  

I know of no PPP implementation that's in the public domain.  All that
are freely available are still copyrighted by their various authors.
And that's The Ohio State University, thank you very much :-)

   DEC may have patented some of their own improvements to PPP (as I
   am sure MST did),

We haven't done anything patentable with PPP or SLIP.  We just have a
nice implementation of the standard specs.

   since PPP has been in the PD for years I do not think they can
   patent the protocol.  Can you patent a protocol anyway????

"Can"?  Apparently.  "Should be able to"?  No.  Protocols and other
software techniques are (through some recent fluke decisions by the US
Patent Office) currently patentable.  That policy is fraught with
problems.  Read prep.ai.mit.edu:pub/lpf/patents.ps and lpf.join for
more information.


In article <1g5m0gINNblt@seven-up.East.Sun.COM> geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
   Skimming comp.protocols.ppp can be misleading. DEC is claiming a
   patent on a 48-bit CRC algorithm.

They have applied for a patent on a technique to use a 48-bit CRC
while two PPP peers are negotiating whether to use a 32-bit CRC or a
16-bit CRC through the rest of their conversations.

   The patent is questionable, IMHO, 

The recent Patent Office policy of granting patents on software is
itself questionable.  But that's off the topic of this forum...

   but in any case the 48-bit CRC is an optional element in PPP, and
   the patent will ensure that it remains a very infrequently
   exercised option....
   
There seems to be little enthusiasm for DEC's idea within the IETF PPP
WG.  Many WG members feel misled because when DEC proposed the
technique in an internet-draft document, there was no mention that
they planned to apply for a patent on it.  It was progressing nicely
through the normal process when someone from DEC mentioned (almost in
an offhand way) that a patent application had been filed.  Interest
quickly waned.

Now some alternative mechanisms have been proposed and are under
consideration.  DEC's negotiation mechanism will probably be one of
several legal options, and some vendors may actually pay their license
fees.  But it's more likely that the rest of the PPP Consortium will
implement one or more of the other possibilities instead.

This patent claim affects only one tiny corner of PPP.  Few users know
or care whether they're using 16- or 32-bit FCS.  Most use 16-bit FCS
because it's the most common default.  And those links that need the
added error detection capability of 32-bit FCS have always been
manually configurable to use it.  Once the link is configured (either
manually or through LCP option negotiations) for one FCS size or
another, everything else progresses in ignorance of the FCS size.

DEC's patent application has inconvenienced users in a relatively
minor way, given them a black eye in the community, and probably
ensured that they're the only ones who will use that technique.

   PPP is alive and well.

Of course.

   (And no. I don't have a date for a PC-NFS PPP :-(
   
(Darn.  That was going to be my next question :-)


In article <Bz1o2I.Iv5@vti.com> cpcahil@vti.com (Conor P. Cahill) writes:
   ronf@panther3.panther.mot.com (Ron Feigen) writes:
      Can you patent a protocol anyway????
   
   That is what Hayes has done with the <min_time>+++<min_time> escape
   sequence for modems, so I guess you can.
   
Yes, for now you can.  See the LPF literature as described above.

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 92 03:40:02 EDT
From:      bruce@camb.com (Barton F. Bruce)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: CSU/DSU that will accept V.25bis dialing commands?

In article <1992Dec04.203341.4178@vpbuild.vp.com>, jessea@u013.me.vp.com (Jesse W. Asher) writes:
> Anyone know of any CSU/DSUs that will accept V.25bis dialing commands?

Not positive, but I would call Adtran (in Huntsville), if I were you.
Their regular DDS DSU/CSU is smart enough to also do sw56, and then they have
models that specifically for sw56 use.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 1992 00:20:04 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?


In article <Byr4oo.I0K@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:

	   I think your interpretation is interesting, but what does it mean to
   "process" the urgent bit without the urgent data? The application can't go
   into "urgent mode" like it's supposed to, because there is no urgent data
   that is deliverable.

Say what? "Urgent mode" means that the application applies different
processing (such as, for example, throwing away all characters except
TELNET IAC commands) to the incoming data stream. It doesn't have
anything at all to do with whether the particular byte indicated by
the urgent pointer is there yet.

"Processing the urgent bit" means telling the application to begin
applying these different interpretation rules. When the app gets to
the place in the stream marked with the urgent pointer, it goes back
to its "normal mode" rules.

				-john
John Wroclawski
MIT Lab for Computer Science
jtw@lcs.mit.edu

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 10 Dec 1992 23:02:25 +01
From:      Paul Bijnens <FFAAC09@cc1.kuleuven.ac.be>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

In article <1992Dec8.170509.3181@acc.com>, art@acc.com (Art Berggreen) says:
>
>In article <92343.102239FFAAC09@cc1.kuleuven.ac.be> Paul Bijnens
><FFAAC09@cc1.kuleuven.ac.be> writes:
>> [ ... ]
>> window    lowwindow       FTP-mode    get         put
>> (bytes)     (bytes)                  (min-max seconds)
>>   1024          0         ASCII       58-59       5-6
>>                           BINARY      7-9         5-6
>>
>>   1024        256         ASCII       7-9         5-6
>>                           BINARY      51-59       5-6
>>
>>
>>
>>We can see in the table that changing the window size has an effect
>>on the performance of ASCII versus BINARY.
>>Has anyone a decent explanation for this behaviour?
>
>For TCP, those are TINY windows (if those numbers really are the TCP
>window).  I believe SUN-OS by default sets the TCP window for the data
>connection to 24K.  I would expect such a small window to make TCP
>a "send one and wait" protocol, with no pipelining.  Also, what are

There are normally 5 buffers in my PC/TCP-implementation.

>your disk I/O subsystems capable of?  When FTPing to DOS systems, we
>find things are usually disk limited.  Also, I would expect much more
>consistancy between ASCII and BINARY times.  Any way of checking TCP
>statistics for retransmissions?

Retransmission count is also 0.

As I said, the problem is exactly the enormous difference between
ASCII and BINARY mode.  Peter Desnoyers suggested that I experiment
again with a file without CR's (protecting the CR's in ASCII could
overflow a buffer that was too small, resulting in transmission of
one full packet and then small with spillover from the previous if
the programming was done lousy).  So I tried a file like this:
    $ perl -e 'print "A" x 167000;' > /usr/tmp/afile
and I got just the same result.

>Trailers should not even be enabled in your environment.  I doubt
>that the hosts would negotiate their use though.

I just mentioned trailers because the PC/TCP manual mentions just
this problem when you have a large difference between get and put
times.

>>(Yes, I know, the Vines network in between is a black box, where
>>everything is to blame for some people.  I do not believe them.)
>
>Is the Compac encapsulating the IP packets in Vines packets across the
>ARCNET?

Yes, the Compac and the PC are connected with a Vines network on
ARCNET.  ARCNET is 2.5 Mbit/sec, and has not much problem to get
effectively about 2.5 Mbit/sec throughput out of it (measured using
the dos command "copy" to just copy a file across the cable).  So
I doubt Vines is the guilty party.
--
Paul Bijnens             -- MS-DOS is the world's most widespread virus.
Linguistics dept., K. University Leuven, Belgium
Polleke@cc1.kuleuven.ac.be

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 1992 03:56:19 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip,comp.sys.mips
Subject:   maximum size of UDP datagrams [ethernet]

According to my calculations, the maximum size of a broadcast UDP
datagram is 1472 bytes, but on our MIPS machines (running RISC/os 4.52)
this does not work. Experimentation reveals that the 'magic number'
on MIPS machines is 1468. Broadcast packets 1472 bytes long work fine
for me on the SGI, SUN and VAX hosts I have tried.

Where did the other 4 bytes go?

calculation:
Broadcast UDP datagram cannot be fragmented, so it must fit into the
1500 byte data portion of an ethernet frame. After sustracting 20 bytes
for the IP header, and another 8 bytes for the UDP header, you are left
with 1472 bytes for user data. [these numbers are based on the diagrams
on page 208 in "UNIX Network Programming" by W. Richard Stevens]

Also, what are the typical limits on regular UDP datagrams?
On our microvax, the max. size is 9000 bytes, while the SGI and
MIPS machines support much larger limits (haven't found the exact
number yet).

Thanks

-- 
Steve Kotsopoulos                   mail:   steve@ecf.toronto.edu
Systems Analyst                     bitnet: steve@ecf.UTORONTO.BITNET
Engineering Computing Facility      uucp:   uunet!utai!ecf!steve
University of Toronto               phone:  (416) 978-5898

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 1992 10:25:50
From:      backman@vaxeline.ftp.com  (Larry Backman)
To:        comp.os.os2.networking,comp.protocols.tcp-ip
Subject:   Re: LPD server from FTP very very ... slow ! Cannot use it!

In article <1992Dec4.130543.23213@edfd.uucp> markus@edfd.uucp (Markus Gruenkorn (MAGIC)) writes:

 >> 
 >> We want to use an OS2 PC as print server using the lpr spooling system.
 >> Using the network stuff from IBM (IBMs TCP/IP) it is working very fast but sometimes the lpd crashes (there are some other problems - new CSD is installed). So I thought to use the stuff from FTP for OS2 . I installed the package and it works without any problems, but if you want to print a bigger file 160kBytes f. e.
 >> it will take over half an hour to print it. (I changed some parameters of the pctcp kernel; buffer size, tcp-recvspace ) to improve performance but it was nearly as slow as before). So I would say the product from FTP is quit good but its lpd server can only be used for small text files.
 >> Can anybody tell me how I can speed up the lpd server because it is not usable right now !


We fixed a number of bugs in the OS/2 LPD in the past year.  Its quite
likely the current shipping version (1.2 PL1) will solve your
problem.  Please contact support@ftp.com for details.

Larry Backman
FTP Software


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 1992 09:07:54 GMT
From:      barre@cenaath.cena.dgac.fr (Roland BARRE)
To:        comp.windows.x,comp.windows.ms,comp.protocols.tcp-ip
Subject:   News reader under MS Windows 3.1?


I am searching a news reader and unix mail reader for microsoft Windows ?

I have an inplementation of pc/tcpip on my pc (racal interlan).

if this product exist could you e-mail me .


thanks
----
-- 
-- 
---------------------------------------------------------
Roland BARRE, barre@dgac.fr
              
Centre d'Etudes de la Navigation Aerienne        

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 1992 14:48:03
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP_URG, does it lower security?

In article <Byr4oo.I0K@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:

       More seriously, even if it falls within the window, you aren't supposed
    to sit on it until you fill in any gaps of data that may appear before the
    urgent data.

Yes, you are, if you subscribe to RFC 793/1122 Urgent (in-band) instead
of 4bsd out-of-band.  You let the application know that Urgent data is
in the pipe, but you have to deliver the bytes in order, including the
ones immediately before and after the Urgent pointer (RFC 793/1122
doesn't specify a single byte as the Urgent one).

I have proof that it is possible to build a TCP API on which you can
do both Telnet Synch and encrypted Klogin (an example of the possible
awkwardness of OOB, since passing the terminal mode as an OOB byte by
nature means that it can't be encrypted along with all the rest of
the data).

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


-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Friday, 11 Dec 1992 09:21:54 CET
From:      <RHUNTER@ESOC.BITNET>
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: Different Subnets on one Ethernet segment?

I would like to leap to the defence of my colleague!

This is NOT risky due to broadcast stroms IF the IP implementations
are bug-free, and you they obey the rules of PROXY-ARP.

I would refer you to RFC1027, which introduces this scheme as a STANDARD.

I would also point out that in a previous life I worked for BP.
Their entire (private) internet is based on this scheme... over 100 Ciscos.
I never saw a broadcast storm in 3 years ;-)

Ray Hunter:
Cray Systems on contract to the European Space Agency
SMTP mail: RHUNTER@ESOC.BITNET
#include <std.disclaimer>

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 92 12:13:43 GMT
From:      bologna@ttd.teradyne.com (Joe Bologna)
To:        comp.protocols.tcp-ip
Subject:   How do I find the PID of a process using a specific socket under SunOS?

Does anyone know how to find the PID of a process using a socket?

For instance, if I use telnet to login from machine "aragorn" to machine
"gandalf", I can find the local TCP port the telnet process is using by
netstat. The following output is obtained.

% netstat
Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      0  aragorn.1047           gandalf.telnet	ESTABLISHED

How do I find the PID of the telnet process on the local machine?

I am running SunOS 4.1.X.

Joe Bologna
Teradyne Inc., Telecommunications Division
Deerfield, IL
bologna@ttd.teradyne.com

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 92 12:34:40 GMT
From:      davidh@CIS.Prime.COM (Dave Hill)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Routing IP over X25

I am having a problem routing IP packets over an X25 WAN using Sunlink
X25 version 7.0. The problem is as follows:-

Using the dynamic interface (std0) in Sunlink X25, I can connect to
hosts that have a different IP network number to my own interface, but I
cannot use those hosts as routers.

Example:- My IP is a class B address xx.xx.1.1, netmask 255.255.0.0 and
I can create a path in the X25 configuration file for a host yy.yy.1.1
i.e. another network.

I can connect to that host OK, so the underlying net is sound. Now, I
want to get to another host, say yy.yy.2.1 on a net for which yy.yy.1.1
is a router. So I say:-

route add net yy.yy.2.0 yy.yy.1.1 1

to which route says "network is unreachable". This is because the kernel
routing code states that the router must be on the SAME network as your
interface. This is normally the case with Ethernet, but can be different
with X25!

So, how do I do it (the simple question!). I have r'ed the FM. I have
tried  using gated but it says the same thing (host is not on an
attached network). I have 'phoned Sun and they said "Errmmm....".

I could use a static IP link and give myself an address on the other
network, but that ties up an X25 Virtual Circuit all the time. 

I could also buy a cisco if I could afford one....

--
Dave Hill                                                  davidh@cis.Prime.COM
Computervision R&D Ltd                                      +44 223 872377 x352
Harston Mill, Harston, CB2 5NH, UK

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 92 13:41:46 GMT
From:      l1ngo@copper.denver.colorado.edu (Linh Ngo)
To:        comp.protocols.tcp-ip
Subject:   Newbie question: IP Routing in loops


I have a few newbie questions that I can't seem to answer with
certainty even with the aid of Comer's Internetworking with TCP/IP Vol I
(great book, though), so I'm turning to the net for some advice.

Here's a picture of the networks, and their routing tables.

(The addresses are sub-netted class 'B' addresses where the
 "x.x" indicates the network address. All machines share the same
 network address though they are at different sites. It's probably
 not the optimum subnetting, but we have to live with it for a while.)

Site 1 has Hell and Fog
Site 2 has Router
Site 3 has Shear and Heaven

         Site 1            Site 2                Site 3

                          +--------+
            +-------------| Router |---------------+
            |             +--------+               |
            | Leased Line                          | Leased line
        +---+----+                           +-----+--+
        | Fog    |                           | Shear  |
        +---+----+                           +-----+--+
            |x.x.195.211 (fog)                     |x.x.194.200 (shear)
            |                                      |
 -----+-----+--------------               ---------+-------+-----------
      |                                                    |
      | x.x.195.100 (hell)                                 |x.x.194.100(heaven)
    +-----+              PPP via Leased Line           +---+---+
    |Hell |--------------------------------------------|Heaven |
    +-----+ x.x.195.116                    x.x.207.65  +-------+
            (hell-ppp)                     (heaven-ppp)


Routing tables for Hell
Destination          Gateway              Flags    Refcnt Use        Interface
heaven-ppp           hell-ppp             UH       1      40988      du3
localhost            localhost            UH       5      217048     lo0
default              fog                  UG       4      107141     ie0


Routing tables for Heaven
Destination          Gateway              Flags    Refcnt Use        Interface
hell                 hell-ppp             UGH      0      2790       du0
hell-ppp             heaven-ppp           UH       0      2234       du0
default              shear                UG       7      679792     le0

Questions:

1. If Heaven starts a TCP session to Hell-PPP, then the source IP address
   is x.x.207.65 and the destination address is x.x.195.116, correct?
   (Thus, the communication between the two machines will only
   go through the PPP link.)

2. If Hell starts a TCP session to Heaven-ppp, then the above still
   applies except the source and destination are swapped, but the
   communication is through the PPP, correct?

3. If Hell starts a TCP session to Heaven, then the source IP address is
   x.x.195.100 and the destination address is x.x.194.100. So traffic
   from Hell to Heaven will traverse Fog-Router-Shear. However, since 
   Heaven has a static route to Hell through Heaven-ppp, the traffic
   back from Heaven to Hell is through the PPP link.  In effect,
   traffic between the two machines will travel in a loop.

   Will the IP routing algorithm on Heaven change the IP source and
   destination addresses to reflect the different routing through the
   PPP link? I remember reading that the IP addresses are NOT
   altered, so I assume that Heaven will send its packets with the
   source of x.x.194.100 and destination of x.x.195.100 even though
   this will be traversing the PPP link.

4. Are IP source and destination addresses simply swapped on the
   receiving end regardless of how it was/is to be routed?

I'm using this information to build some scripts to modify the routing
tables should the PPP or the alternate route fails. I'd like to provide
some redundancy in case a machine/line fails, but also I'd like to make the
best use of available bandwidth when both routes are up.

Thanks in advance,
Linh
--
Linh Ngo, System Administrator    |  Email:  l1ngo@copper.denver.colorado.edu
Wyndemere, Inc., Boulder CO       |  Voice:  303.651.4288 Fax: 303.441.0452
UCD Computational Math, Denver CO |  Voice:  303.556.4827 Fax: 303.556.4822

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 1992 13:59:37 GMT
From:      ramon@helix.nih.gov (Ramon J. Hontanon)
To:        comp.dcom.lans.ethernet,vmsnet.networks.misc,comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc
Subject:   Network Engineer Certification (HOW? WHERE?)

Not long ago, I came across the term "Certified Network Engineer" in a
computing magazine (can't remember which one). My job includes a lot
of local networking, and I'm becoming very interested in such topics,
so I thought I'd tap the collective knowledge of this forum.

- Where can I get this certification? Any locations in the Maryland-
  D.C.-Virginia area?

- What is the course load like? Is it a seminar(s) or simply a test?

- What is the approximate cost involved?

Any experiences (direct or indirect) would be greatly appreciated!

Thank you in advance and Happy Holidays!

Ramon J. Hontanon   ramon@helix.nih.gov
CBER FDA NIH
Bethesda, MD



-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 1992 14:00:08 GMT
From:      vish@nd.edu (Vishwamber Yelsangikar)
To:        comp.protocols.tcp-ip
Subject:   INFO ON ANY CONFERENCE NEEDED

I would like to know name, place and date of any networking or Unix
related conference to be held outside of US or a magazine or newsgroup
where I can get this info.

Thanks...

Vishwamber Yelsangikar
Network Engineer.
Notre Dame.

Go Bills!!!!
Go Irish!!!!

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 92 16:17:05 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.sys.mips
Subject:   Re: maximum size of UDP datagrams [ethernet]

In article <Bz2tLw.JH5@ecf.toronto.edu>, steve@ecf.toronto.edu (Steve Kotsopoulos) writes:
> ...
> Also, what are the typical limits on regular UDP datagrams?
> On our microvax, the max. size is 9000 bytes, while the SGI and
> MIPS machines support much larger limits (haven't found the exact
> number yet).


That number on an SGI  machine can be found or changed in the variable
udp_sendspace in /usr/sysgen/master.d/bsd.  After changing it, run the
command /etc/autoconfig and follow its instructions to reboot the system.


Vernon Schryver, vjs@sgi.com

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 92 16:53:07 GMT
From:      ric@updike..sri.com (Richard Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Multiport repeaters and collision propagation


	I am working with a hardware networking engineer who is helping
me figure out why packets appear to be dropped when they are
transmitted between a SUN fileserver in one building and a client
SUN in another.  Between the buildings are a 2-port Xerox repeater,
a Codenoll multiport fiber optic star and a TCL multiport repeater.
Both Suns are connected to Thicknet on ports of a multiport
transceiver.

	He claims that it is not uncommon for multiport repeaters
and even transceivers to NOT propagate collision signals to
nodes on the repeater where the collision did not occur.  In other
words,  he says that some multiport devices isolate collision signals
to the branch where they occur.  Can anyone confirm such behavior?
If this is indeed happening, can it not cause problems if a computer
a node or more away is unaware of a lost packet(s) it transmitted.  A 
timeout would need to occur and a retransmission request sent?

	The symptoms we have seen are very long file transfer times
(via NFS) and slow interactive response on X terminals on machines
in a different building from the fileserver (and X client machine).

	Any comments, suggestions or recommendations would be 
appreciated.  Thank you.

regards,

	ric steinberger
	ric@updike.sri.com


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Dec 1992 19:33:48 GMT
From:      tdyck@fraser.sfu.ca (tReVoR)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.internals,comp.unix.programmer,comp.unix.misc
Subject:   if(7) network driver info needed

I am developing a STREAMS device driver under Microport Unix SVR4 on a
486 machine.  The driver is for a network card (ISDN).

I wish to link the STREAMS driver under the IP module, so that the
card can be accessed in the same way as an Ethernet card through
TCP/IP.  The network interface standard, as I understand from reading
through the documentation, is specified by if(7).  

Does anyone know if there is any way I can get more info on if(7)?  Right
now all I have is the manual page from the Network User's and Administrator's
Guide.  

In the manual page for if(7), it says that "network interfaces used by the
Internet Protocol (IP) must be STREAMS devices conforming to the Datalink
Provider Interface (DLPI)."  Does anyone know what the DLPI is and where
more information can be found about it?

Also, does anyone have experience with writing similar network interface
drivers (ie. for Ethernet or some other network)?



Any help is GREATLY appreciated!  

Trevor.


-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 92 00:05:41 GMT
From:      doug@aptzero.lonestar.org (Doug Gault)
To:        comp.windows.x,comp.windows.ms,comp.protocols.tcp-ip
Subject:   Re: News reader under MS Windows 3.1?

barre@cenaath.cena.dgac.fr (Roland BARRE) writes in COMP.WINDOWS.MS:

> I am searching a news reader and unix mail reader for microsoft Windows ?
> 
> I have an inplementation of pc/tcpip on my pc (racal interlan).
> 
> if this product exist could you e-mail me .
> ---------------------------------------------------------
> Roland BARRE, barre@dgac.fr
>               
> Centre d'Etudes de la Navigation Aerienne        

I also would like to get ahold of a mail reader for windows.. I, however
am running a version of WAFFLE for dos under Windows 3.1.. The Messages
seems to be formated differently, and have an index file associated with them.

Any one know of a mail Reader (or a WINDOWS to WAFFLE front end) that would 
do the trick?

Doug

==================------------------------------------------------------------
=  ____________  =  Doug Gault                | ".. On the other hand, life  -
=  \          /  =  Hm 214-320-9426           |  can be an endless parade of -
=   \        /   =  Wk 214-392-0955           |  TRANSSEXUAL QUILTING BEES   -
=    \      /    =                            |  on a cruise ship to DISNEY  -
=     \    /     =  doug@aptzero.lonestar.org |  LAND, if only we let it!! " -
=      \  /      =                            |                              -
=       \/       =                            |                              -
==================------------------------------------------------------------

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Dec 92 18:37:27 CST
From:      mike@maria.wustl.edu
To:        comp.protocols.tcp-ip
Subject:   Can I use a secondary name server as a primary Hesiod server?


For political reasons, I can't be the primary nameserver for my own
group of machines.  I have a secondary nameserver set up so my machines
don't have to go off to hell and backto get nameservice.  (This machine
is listed first in the clients' resolv.conf files.)  

I'd like to distribute things like /etc/passwd, /etc/group, and whatnot
through Hesiod.  (It ships with the DECs -- supposedly this makes life
easy.)  However, I have no control over my primary name server.  I *do*
however have maximum control over my secondary which all my clients point
to first.  

With this configuration, is it possible to run my secondary name server
as a primary Hesiod server?  If so, how?  I've never run Hesiod before
and if this is some sort of FAQ or misposted, my apologies to all concerned
in advance.  Thanks!

-Mike
mik!e@maria.wustl.edu
(or something like that)

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Dec 1992 22:49:24 GMT
From:      jpsb@gothamcity.jsc.nasa.gov (Jim Shirreffs)
To:        comp.protocols.tcp-ip
Subject:   SLIP Cookbook or FAQ neded

Hi Is there ANY documentation around that would help me 
with setting up SLIP for my home Unix system? I've got
a 486 running SVR4 Unix.

Thanks in advance

Jim Shirreffs



-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Dec 1992 00:43:46 GMT
From:      rsivaram@vela.acs.oakland.edu (Siva)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Re: WANTED: TINY FTP CLIENT

In article <AMOSS.92Dec7152844@shuldig.cs.huji.ac.il> amoss@shuldig.cs.huji.ac.il (Amos Shapira) writes:
>In article <1992Dec4.220356.25115@sfu.ca> rchen@fraser.sfu.ca (Robert Chen) writes:
>
>   Hi.  I am looking for a "tiny ftp", using BSD type sockets.  Basically,
>   I am looking for some stripped down version that is just capable of
>   loggin in and receiving a binary file, and possibly reading a remote
>   directory, but nothing else.
>
>   - Ken
>
>I made a small ftp client library I wrote available on ftp.huji.ac.il
>directory pub/network/ftplib-0.1.tar.Z.  It's rough but does the work you
>want.  Please e-mail me if you need any help with it.
>
>(I'm following up to c.p.tcp-ip since I think it might be interesting to
>others,  hope I'm right).
>
>Cheers,
>--
>--Amos Shapira (Jumper Extraordinaire)
>C.S. System Group, Hebrew University, Jerusalem, Israel
>amoss@cs.huji.ac.il

I modified the PD FTP source code and wrote a program to read a remote
ascii file. I can make some slight modifications for binary file.
If you need it pl e-mail me. I can send it to you
-Cheers
Siva
-- 



-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 1992 16:46:10 GMT
From:      5247cuid@vms.csd.mu.edu
To:        comp.protocols.tcp-ip
Subject:   What is the meaning of LAT

Dear netters:

	What is the meaning of LAT and what is it used for and how is it
implemented?


	Thanks in advance.

	Sincerely Yours,


	Dayong Cui

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Dec 1992 18:31:14 GMT
From:      rustomji@sol.cs.wmich.edu (Eric Rustomji)
To:        comp.protocols.tcp-ip
Subject:   Help: getpeername(), getsockname() calls

Hi there,

I was trying to use the BSD socket calls, on my client-server
project:

getpeername(s, name, namelen)
int s;
struct sockaddr *name;
int *namelen;

where, I allocated:
struct sockaddr clnt_name;
int clnt_name_len;

main()
{
    .
    .
    clnt_name_len = sizeof(clnt_name);
    getpeername(sockfd, &clnt_name, &clnt_name_len);
    .
    .
}

I observed that after the getpeername() call, the variable clnt_name
contains this:

clnt_name.sa_family = 2
clnt_name.sa_data = "p ( >"   --->> ????

Could anyone let me know, whats happening here. I dont seem to
be getting the endpoint connection/remote address of the socket.

I would appreciate if any ideas/reference could be sent to me ASAP
at my email address: 
rustomji@cs.wmich.edu

Thanks a bunch! Happy Holidays !!

--
Eric


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Dec 1992 03:14:45 GMT
From:      goldstein@carafe.enet.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the meaning of LAT


In article <0096505C.AF7E4620@vms.csd.mu.edu>, 5247cuid@vms.csd.mu.edu writes...
>	What is the meaning of LAT and what is it used for and how is it
>implemented?

Perhaps you are referring to the DEC protocol "LAT", used in terminal 
servers, Pathworks, etc.?  It stands for Local Area Transport, a 
nonroutable protocol most often used to provide terminal services across 
Ethernet.  It's implemented in lots of DEC gear and is licensed to many 
others.
---
Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Dec 1992 09:35:03 GMT
From:      cslee@pds.nchu.edu.tw (Lee Chee Siong)
To:        comp.protocols.tcp-ip
Subject:   Wanted: SLIP script for Xyplex terminal server

   Could someone tell me how to get a SLIP script for using in XYplex terminal
server? I know that there is a few in Cisco but what I need is for XYplex.
   Any suggestion is appreciate.

	

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<>   CS Lee	(Lee Chee Siong)		<>  If you can give	<>
<>   National Chung Hsing University,		<>	  nothing else, <>
<>   Taichung, Taiwan, Republic of China.	<>  at least give a	<>
<>   Internet Address: cslee@pds.nchu.edu.tw	<>	  cheerful face <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 92 09:44:37 GMT
From:      jbn@stl.dk (Jens Bloch Nielsen)
To:        comp.unix.ultrix,comp.protocols.tcp-ip
Subject:   ULTRIX 4.2A rsh- or TCP/IP-problem.

We have some DECstation 5000/125 and DECsystem 5000/200 running 4.2A 
connected by ethernet (TCP/IP). When we try execute a remote shell (rsh) 
from one system to another in order to run a command (a script or a 
system-command), the rsh sometimes hangs (never exits). The command 
or script is always executed as expected, but the rsh never exits.

A netstat shows that the TCP/IP-connection is not closed correctly. 
There is a CLOSE_WAIT on the local machine (the system from which the 
rsh was issued) and a FIN_WAIT_2 on the remote system.

This indicates that the connection has been closed on the remote machine 
but the local machine never receives the close-ack.

Example:

If we issue the following command on the system tst05:

	rsh tst01 dobackup.x

Dobackup.x is a script that executes find-commands and rcp-commands 
on tst01/tst05.


a netstat after termination of the script on tst01 and tst05 shows (not
all tcp-connections shown):

tst05:

Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
	..
	..
tcp        0      0  tst05.1020             tst01.1021             CLOSE_WAIT
tcp        0      0  tst05.1021             tst01.shell            CLOSE_WAIT
	..
	..

tst01:

Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
	..
	..
tcp        0      0  tst01.1021             tst05.1020             FIN_WAIT_2
tcp        0      0  tst01.shell            tst05.1021             FIN_WAIT_2
	..
	..


Does anyone know this problem and perhaps a method to avoid it. ??
Is there bug in a ultrix systemcall (used by rsh), rsh or TCP/IP
that could cause this problem ??

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Dec 1992 19:38:52 GMT
From:      chk@alias.com (C. Harald Koch)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiport repeaters and collision propagation

In <ric.724092787@updike> ric@updike..sri.com (Richard Steinberger) writes:

>	He claims that it is not uncommon for multiport repeaters
>and even transceivers to NOT propagate collision signals to
>nodes on the repeater where the collision did not occur.  In other
>words,  he says that some multiport devices isolate collision signals
>to the branch where they occur.  Can anyone confirm such behavior?

I have been having problems with several machines on our Ethernets here,
that could be caused by this. (They could also be caused by malfunctioning
hardware, non-compliant transceivers; etc.; but several repeaters exhibit
the same symptoms, so I'm pretty sure it's the repeater itself).

What I'm seeing is strange; I can blast data over a TCP/IP connection at
over 800Kb/s from host A to host B, but throughput is around 20Kb/s in the
reverse direction. Blasting UDP data across the network shows extremely high
packet losses in one directory.

There are two multi-port repeaters between the hosts; all cabling is
thin-Ethernet. All of my test hosts are the same (SGI Indigos with Allied
Telesis Micro-transceivers, all running the same OS revision).

Hosts that are both on the same local thin-net cable (i.e. not talking
through a repeater) can talk to each other at high-speed, bi-directionally,
without problems. Also, not all repeaters show these symptoms.

I've been monitoring packets on the cables lately to try to figure out
what's wrong. If I run monitors on machines 'next to' A and B, I see many
packets transmitted by machine B, but that never appear on machine A's
cable. The only conclusion I've reached so far is that for some reason, the
repeater is dropping packets. (This is supposed to be impossible, due to
collision propogation and Ethernet's exponential backoff). Incidentally,
netstat on the transmitter shows no output errors and no dropped packets.

Different manufacturer's repeaters behave differently (even when replaced by
each other), but so far the problem is consistent to certain manufacturers,
which is why I suspect a design flaw of some sort.

I'm sorry this is so anecdotal, but I'm still running tests and collecting
data (This is difficult on an operational network, and I don't have the
resources for a test net).

If you find any more concrete information, I'd love to hear about it!

--
Main's Law: For every       | C. Harald Koch  Alias Research, Inc. Toronto, ON
action, there is an equal   | chk@alias.com                (work-related mail)
and opposite goverment      | chk@gpu.utcs.utoronto.ca     (permanent address)
program.                    | VE3TLA@VE3OY.#SCON.ON.CA.NA            (AMPRNet)

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Dec 1992 19:43:47 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Engineer Certification (HOW? WHERE?)

Ramon J. Hontanon:
> Not long ago, I came across the term "Certified Network Engineer" in a
> computing magazine (can't remember which one). My job includes a lot
> of local networking, and I'm becoming very interested in such topics,
> so I thought I'd tap the collective knowledge of this forum.

You need to take an exam from Novell to become a CNE.  This means taking
classes provided by Novell or from a Certified Novell Instructor (CNI).
This will probably cost you big bucks, but you'll get a complete set of
Novell manuals from taking the classes.

Novell networking has very little to do with TCP/IP.

- Steve Kao

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 92 19:47:53 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip,comp.sys.mips
Subject:   Re: maximum size of UDP datagrams [ethernet]

In article <Bz2tLw.JH5@ecf.toronto.edu>, steve@ecf.toronto.edu (Steve Kotsopoulos) writes:
|> According to my calculations, the maximum size of a broadcast UDP
|> datagram is 1472 bytes, but on our MIPS machines (running RISC/os 4.52)
|> this does not work. Experimentation reveals that the 'magic number'
|> on MIPS machines is 1468. Broadcast packets 1472 bytes long work fine
|> for me on the SGI, SUN and VAX hosts I have tried.
|> 
|> Where did the other 4 bytes go?

Your calculations are correct.  My guess is that you have an
"eagle" ethernet board in your system (e.g. egl0).  If you
look at the "netstat -i" display you will discover that the
MTU size is "1496" and not "1500".  The reason for the decrease
in size was do to a DMA problem.  I don't know whether
the board has ever been fixed but the code still assumes
the bug exists.  The problem is only on the sending side since the
board can receive 1500 byte packets (i.e. otherwise it would
not interoperate with other systems sending 1500 byte packets).

NOTE - the integrated ethernets (e.g. la0) on the MIPS boxes
use the "1500" byte MTU.


|> 
|> calculation:
|> Broadcast UDP datagram cannot be fragmented, so it must fit into the
|> 1500 byte data portion of an ethernet frame. After sustracting 20 bytes
|> for the IP header, and another 8 bytes for the UDP header, you are left
|> with 1472 bytes for user data. [these numbers are based on the diagrams
|> on page 208 in "UNIX Network Programming" by W. Richard Stevens]
|> 
|> Also, what are the typical limits on regular UDP datagrams?
|> On our microvax, the max. size is 9000 bytes, while the SGI and
|> MIPS machines support much larger limits (haven't found the exact
|> number yet).
|> 
|> Thanks
|> 
|> -- 
|> Steve Kotsopoulos                   mail:   steve@ecf.toronto.edu
|> Systems Analyst                     bitnet: steve@ecf.UTORONTO.BITNET
|> Engineering Computing Facility      uucp:   uunet!utai!ecf!steve
|> University of Toronto               phone:  (416) 978-5898

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Dec 1992 21:58:07 GMT
From:      ffuentes@tolten.puc.cl (Fernando Fuentes SCC)
To:        comp.protocols.tcp-ip
Subject:   EDI over TCP/IP

I would like to know if there are experiencies with EDI over TCP/IP, and
how did they worked.
I know that EDI works fine over X.400 and that there is X.400 working
over TCP/IP. I think that this could be one solution. I there are any
comments, please send them to me.
I would like to know also if there is another way to put EDI over
TCP/IP, and what EDI is that (I am not sure but I have heard that there
is another stantar than ISO EDI/EDIFACT)

Thanks for your cooperation


Fernando Fuentes
SECICO 
Pontificia Universidad Catolica de Chile
Vicuna Mackenna 4860, Santiago, Chile 
ffuentes@tolten.puc.cl 

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Dec 1992 01:23:50 GMT
From:      quandt@mcs213g.cs.umr.edu (Brian Quandt)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   ATM


First , is this an appropriate newgroup to talk about ATM networks?

If so...

	Where can I find out (any recommended papers, articles) about what
makes ATM?

	Are there any suppliers of ATM style networking cards for ISA and
	EISA busses?  I'd appreicate hearing recommendations if any
	What about on the amiga (zorro III bus)?

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1992 02:07:52 GMT
From:      soloway@midniteoil.Eng.Sun.COM (Mark Soloway)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast in SUNOS 4.1.3

In article 8672@uxmail.ust.hk, clfung@uxmail.ust.hk (Fung Chi Leung) writes:
>Our system has upgraded to SUNOS 4.1.3 recently. As I heard from the news, 
>it can support multicasting, right?  Can anyone out there give me any examples
>or guides of how to program the multicasting functions?  

I'm not sure about specific kernel multicast message support, but ToolTalk (a
multicast message service) ships with OpenWindows 3.0 and later.  Your OpenWindows
Document Set should include a "ToolTalk Programmer's Guide".  Also, Answerbook
contains the "ToolTalk Programmer's Guide" in the "System Services" section...

		- Mark
__________________________________________
\_Mark Soloway (mark.soloway@Eng.Sun.COM)_\
/_Distributed Systems Services (ToolTalk)_/
\__SunSoft (A Sun Microsystems Company)___\


-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 92 12:09:10 EST
From:      jkidwell@pbs.org
To:        comp.protocols.tcp-ip
Subject:   Multi-cast Transport Protocols

Greetings:

We are designing a VSAT WAN based on TCP/IP and need to improve throughput.
Because much data is shared amoung many sites, multi-casting is potentially
more efficient than N uni-casts.  For example, we need to disseminate a
multimedia hypercard stack to all PBS member stations, but uni-casting takes
too long over a relatively slow VSAT connection.

In RFC-1112 Deering describes extensions for IP multi-casting, limiting
the discussion to the IP layer.  Upper-level protocols are implied, but
not discussed.

Please email suggestions and references to relevant literature about 
data broadcasting protocols to jkidwell@pbs.org.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Dec 1992 08:18:32 GMT
From:      etxmesa@eos.ericsson.se (Michael Salmon)
To:        comp.protocols.tcp-ip
Subject:   Is VMTP used?

I am currently planning to RPC's as a means of communicating between
computers. I had thought that I would use UDP mainly, as NFS is one of
the requirements, with TCP as an option. In looking through the RFC for
RPC I noticed a reference to VMTP which the author seems to think is
ideally suited for RPC's, however I have not heard mention of this
protocol previously. My question is therefore does anyone use VMTP for
RPC's ?

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Dec 1992 13:05:45 GMT
From:      mark@mcs.spb.su (Mark Orlov)
To:        comp.protocols.tcp-ip
Subject:   Re: ICL OSLAN

>   In article <Bz1KJo.Ksu@atlas.abccomp.oz.au> phil@atlas.abccomp.oz.au (Phil Stenson) writes:
>
>   >    Over the past few months my search has been directed largely at
>   >ICL directly and with the exception of one or two people within that
>   >organisation I do not even get the courtesy of any form of response to
>   >my requests for information.
>
>   As it turns out 4 days after submitting this article I finally did receive
>   a reply from ICL - the reason for the delay turns out to be a typo in
>   the e-mail address to which the person from ICL has been trying to send.
>
>   >    I have addressed this query to a few of the comp.protocols
>   >groups for two reasons:
>   >
>   >        1. hopefully somebody may have some information for me
>   >
>   >        2. for a company that professes to be an Open System
>   >           company they certainly behave very much like a
>   >           very Closed System company.
>
>   Point 2. in light of the above is not applicable (was more a case of venting
>   some frustration).
>
>

  Our company sells solutions based on ICL products in former Soviet
  Union.
  I work on ICL DRS 6000 and DRS 3000 with SVR4. I mostly use TCP/IP
  connections for PC's and OSLAN for UNIX boxes.
  It's very pleased to find somebody who works (?) with ICL products.
  I will be very glad if you join me in investigation of ICL
  hard/software.


--
        Thanks and best Regards

        Mark Orlov,                          <mark@mcs.spb.su>
        Head of UNIX systems department,     Voice: +7 (812) 5683952
        Marine Computer Systems (ICL)
        St. Petersburg,  Russia.



-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 92 13:57:23 GMT
From:      bvs@nrc.com (Bill Versteeg)
To:        comp.protocols.tcp-ip
Subject:   looking for systems with BOOTP server


Hello folks-

I am designing a device that will use bootp to
get some info, then use tftp to download a file
and run. I have a good handle on the client side stuff,
but I can't find stock systems that support running a bootp 
server. I can do it in my lab just
fine, (using the CMU public domain stuff), but 
I hate to recommend this option to customers.
I would prefer a commercially supported product.

So, this is an invitation to vendors of products
that support BOOTP server mode to send me some info (8-)).

Please send blatent plugs to me, not the net. If you have
something the net may be interested in, post away, but please
don't use this note as an exuse to advertise to the net.....

Bill VerSteeg
bvs@ver.com


-- 
Bill VerSteeg
VerSteeg CodeWorks
bvs@nrc.com

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 92 14:59:15 GMT
From:      avalon@coombs.anu.edu.au (Darren Reed)
To:        comp.protocols.tcp-ip
Subject:   Port Allocation.

When allocating ports for program use, it is commonly recognized that
under 1024 is priveledged as per the latest numbers RFC.  A small space
of this (usu between 1000 and 1024) is used by the "r" commands.

Then what ?  From /usr/include/netinet/in.h:

/*
 * Ports < IPPORT_RESERVED are reserved for
 * privileged processes (e.g. root).
 * Ports > IPPORT_USERRESERVED are reserved
 * for servers, not necessarily privileged.
 */
#define IPPORT_RESERVED         1024
#define IPPORT_USERRESERVED     5000

Does this imply that nfs should be on a port > 5000 or that OpenWindows/
Openlook shouldn't be at 2000 and that most rpc services are definately
in the wrong place ?

What about NCSA telnet which *always* has a local port >16384 for any
connection, be it telnet or ftp ?

darren

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 92 15:09:49 GMT
From:      mccalld@vax.sonoma.edu
To:        comp.protocols.tcp-ip
Subject:   'ftppass'file format ?

Greetings:

     I've just configured my mac as a host and I'm using the generic
NCSA telnet software....I can't find the documentation which describes
the format for the 'ftppass' file.....any help would be appreciated
mccalld@sonoma.edu

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Dec 1992 15:27:44 GMT
From:      mshah@next3.corp.mot.com
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   ROOT Server Problem ??

I noticed that I was not getting the right info. when I was querying the root  
server "ns.nic.ddn.mil" about an internet domain (osf.org), Instead of  
returning the correct nameservers it was returning our local root nameservers  
as the authoritative for that domain. Please note that the domain name is not  
ended with a trailing dot in the nslookup that I have done below:

---------------------
> osf.org
Server:  ns.nic.ddn.mil
Address:  192.112.36.4

Authoritative answers can be found from:
MOT.COM nameserver = MOTGATE.MOT.COM
MOT.COM nameserver = FTPBOX.MOT.COM
MOT.COM nameserver = NISCA.ACS.OHIO-STATE.EDU
MOT.COM nameserver = NIC.NEAR.NET
----------------------

The above  is not right information (i.e motgate and ftpbox are not  
authoratative  servers for osf.org domain). This can be illustrated by changing  
the server to  say "ns.nasa.gov" and doing an nslookup again. In the following  
nslookup output with server as ns.nasa.gov, eventhough the doamin name is not  
ended with a trailing dot, the nameserver comes up with the right information. 

-----------------------
> server NS.NASA.GOV
Default Server:  NS.NASA.GOV
Addresses:  128.102.16.10, 192.52.195.10

> osf.org
Server:  NS.NASA.GOV
Addresses:  128.102.16.10, 192.52.195.10

Non-authoritative answer:
osf.org nameserver = POOCH.OSF.ORG
osf.org nameserver = PAPERBOY.OSF.ORG
osf.org nameserver = MAILBOX.OSF.ORG
osf.org nameserver = NIC.NEAR.NET

Authoritative answers can be found from:
OSF.ORG nameserver = POOCH.OSF.ORG
OSF.ORG nameserver = PAPERBOY.OSF.ORG
OSF.ORG nameserver = MAILBOX.OSF.ORG
OSF.ORG nameserver = NIC.NEAR.NET
POOCH.OSF.ORG   internet address = 130.105.1.156
PAPERBOY.OSF.ORG        internet address = 130.105.1.137
MAILBOX.OSF.ORG internet address = 130.105.1.8
NIC.NEAR.NET    internet address = 192.52.71.4
-----------------------

My question is why is there an anamoly in the information that the root server
"ns.nic.ddn.mil" is giving out or there is a misunderstanding on my part. 
Thanks in advance.

--Manish Shah

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1992 15:53:39 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Port Allocation.

In article <avalon.724431555@coombs> avalon@coombs.anu.edu.au (Darren Reed) writes:
>When allocating ports for program use, it is commonly recognized that
>under 1024 is priveledged as per the latest numbers RFC.

Check RFC 1122 on "privileged" ports: No ports are "privileged", except by
convention of some OS's.  This convention can NOT be assumed to exist outside
of that particular OS.  The only difference about ports under 1024 is that
they are used for well-known ports and therefore, non-RFC protocols should
probably not use ports in that range.  (BTW, when 1122 was written, there
were only 256 well-known ports.  The argument still applies, though.)

All the specs say now are that ports under 1024 are to be used for well-known
ports.  Ports above 1024 are technically a free-for-all, though individual
operating systems may choose to allocate them in whatever arbitrary way they
like.  BSD does so, in an admittedly arbitrary way.

The NCSA telnet allocations you saw were fine.  The telnet I use here starts
with local port 65534 and works its way down to 1024, then wraps around to
65534 again.  The wrap around could be at 1 were it not for some design
compromises (read: bugs) in the way it handles multiple connections on the
same local port.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 92 17:23:43 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.sys.mips
Subject:   Re: maximum size of UDP datagrams [ethernet]

In article <Bz2tLw.JH5@ecf.toronto.edu> steve@ecf.toronto.edu (Steve Kotsopoulos) writes:
>Broadcast UDP datagram cannot be fragmented, so it must fit into the
>1500 byte data portion of an ethernet frame. After sustracting 20 bytes
>for the IP header, and another 8 bytes for the UDP header, you are left
>with 1472 bytes for user data. [these numbers are based on the diagrams
>on page 208 in "UNIX Network Programming" by W. Richard Stevens]

I believe that not fragmenting broadcasts is a "BSD-ism", and is not explicitly
illegal in the IP spec.  But because of this defacto rule, and that broadcasting
fragments affects every IP station (consuming reassembly resources), it's
probably a a good thing to avoid.

Art

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 92 17:33:48 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Routing IP over X25

In article <1992Dec11.123440.17671@medusa.prime.com> davidh@CIS.Prime.COM (Dave Hill) writes:
>I am having a problem routing IP packets over an X25 WAN using Sunlink
>X25 version 7.0. The problem is as follows:-
>
>Using the dynamic interface (std0) in Sunlink X25, I can connect to
>hosts that have a different IP network number to my own interface, but I
>cannot use those hosts as routers.
>
>Example:- My IP is a class B address xx.xx.1.1, netmask 255.255.0.0 and
>I can create a path in the X25 configuration file for a host yy.yy.1.1
>i.e. another network.
>
>I can connect to that host OK, so the underlying net is sound. Now, I
>want to get to another host, say yy.yy.2.1 on a net for which yy.yy.1.1
>is a router. So I say:-
>
>route add net yy.yy.2.0 yy.yy.1.1 1
>
>to which route says "network is unreachable". This is because the kernel
>routing code states that the router must be on the SAME network as your
>interface. This is normally the case with Ethernet, but can be different
>with X25!

Sorry, but fairly fundamental to IP routing, is the assumption that for two
nodes to communicate directly, that they both have interfaces on a common IP
(sub)network.  The traditional way for routers to deal with media like X.25
that often support multiple logical IP (sub)networks is to configure multiple
IP addresses on those interfaces for the logical IP networks they need to
communicate over.  The introduction of SMDS and ATM technologies have brought
some of these issues back into focus are are being actively discussed (especially
in the IPLPDN working group of the IETF).

Art

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Dec 1992 18:31:39 GMT
From:      mikes@techbook.com (Mike Scheuerman)
To:        comp.protocols.tcp-ip
Subject:   NSCA terminal emulator

We are in the process of installing a large LAN supported by a Unix
server running portable Netware and we need to be able to connect to
the host in normal terminal mode thru the LAN.  I understand that
NSCA has a pretty good terminal emulator that is in the public domain
and therefor inexpensive :-).  Does anyone know 1) if my information
is correct and 2) if so how one goes about getting a copy of the
emulator.

The workstations are PCs and the network is TCP/IP based.

Thanks in advance for your help.

Mike Scheuerman  
(mikes@techbook.com)

-- 
mikes@techbook.COM  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at (503) 220-0636 (1200/2400, N81)
-------------------------------------------------------------------------
PhoneNet: 503/227-0600   

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Dec 1992 19:30:20 GMT
From:      gogan@hermes.oit.unc.edu (Jim Gogan)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   NCSA Telnet/MacTCP/Mac LC


We have been experiencing an on-going problem that, now that the semester is winding
down, we're trying to push to find an answer to.   Basically, we have found that it
is very easy (just by typing real fast, for example) to lock up an LC running telnet
sessions (doesn't matter to which hosts) with:
 - NCSA Telnet (either version 2.3 or 2.5)   AND
 - MacTCP (version 1.1)
Doesn't matter what brand of Ethernet adapter in the Mac; doesn't matter whether I'm
running System 6 or 7.

We do NOT have this problem running SU/Mac and MacTCP, nor do we have this problem
running NCSA ver 2.5 with hardware=ether.
Has anyone else seen this?

One interesting point that may be relevant.  I connected our lil'ol'Lanalyzer,
filtering for packets to-from the Mac LC I was working on.  And noticed the
following:
  - when using NCSA Telnet with hardware=ether, the TCP Window size used by the Mac
is whatever I specify with the rwin= parameter in config.tel (no surprise there); I
used values from 512 to 4096 -- all was OK;
  - when using SU/Mac IP with MacTCP, the TCP Window size used by the Mac is 1336;
  - HOWEVER, when using NCSA Telnet with MacTCP, the TCP Window size supposedly used
by the Mac (as shown in the packet trace) is 4788; that just seems kinda odd to me. 
Of course, the rwin parameter in config.tel has no effect if you're using MacTCP.

Any liklihood that this is related to our problem, and, if so, is there any way to
change parameters like this for MacTCP (or is it up to the application to deal with
that)?

Pointers will be - as always - greatly appreciated.  Please respond to me directly
thru e-mail.  I'll post the appropriate response (if any).
Thanks!

-- Jim Gogan (Jim_Gogan@unc.edu)
   OIT Networking Systems
   University of North Carolina at Chapel Hill

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1992 19:31:14 GMT
From:      soloway@midniteoil.Eng.Sun.COM (Mark Soloway)
To:        comp.protocols.tcp-ip
Subject:   Re: Multicast in SUNOS 4.1.3

In article liqffoINNq8t@appserv.Eng.Sun.COM, soloway@midniteoil.Eng.Sun.COM (Mark Soloway) writes:
>In article 8672@uxmail.ust.hk, clfung@uxmail.ust.hk (Fung Chi Leung) writes:
>>Our system has upgraded to SUNOS 4.1.3 recently. As I heard from the news, 
>>it can support multicasting, right?  Can anyone out there give me any examples
>>or guides of how to program the multicasting functions?  
>
>I'm not sure about specific kernel multicast message support, but ToolTalk (a
>multicast message service) ships with OpenWindows 3.0 and later.  Your OpenWindows
>Document Set should include a "ToolTalk Programmer's Guide".  Also, Answerbook
>contains the "ToolTalk Programmer's Guide" in the "System Services" section...

For the people who have responded to me directly about my post:

I am quite aware of the IP Multicast support in Solaris 2.X (SunOS 5.X).  My reason
for mentioning ToolTalk is that ToolTalk IS a multicast IPC service and it provides
the level of multicast messaging required by a large variety of applications.  For
relevance to this news group, ToolTalk is layered on top RPC using TCP/IP for
transport.

						- Mark
__________________________________________
\_Mark Soloway (mark.soloway@Eng.Sun.COM)_\
/_Distributed Systems Services (ToolTalk)_/
\__SunSoft (A Sun Microsystems Company)___\


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1992 22:45:54 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: NCSA Telnet/MacTCP/Mac LC

gogan@hermes.oit.unc.edu (Jim Gogan) writes: HOWEVER, when using NCSA Telnet
> with MacTCP, the TCP Window size supposedly used by the Mac (as shown in
> the packet trace) is 4788; that just seems kinda odd to me.  Of course,
> the rwin parameter in config.tel has no effect if you're using MacTCP.

	I wonder if this is in any way related to the extremely slow
performance we get with Telnet.  We run NCSA Telnet 2.4 and 2.5 on
Mac-IIci's running 7.0.1 w/ MaTCP 1.1 or 1.1.1 on a relatively lightly
loaded thin ether segment.  Telnetting to an otherwise idle Ultrix box
sitting right next to my Mac, I get performance (for big blocks of text,
full screen updates in a 40-line window) that seems to me to be about on a
par with a 9600 bps connection.  Currently, I'm at home running kermit (also
with a 40-line screen size) over a 19.2 V.32bis connection to a terminal
server telnetting to that same Ultrix box through GOK how many bridges,
repeaters, etc and getting performance which is about as good.
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 92 23:55:26 GMT
From:      shuenn@tora.swdc.stratus.com (serene2)
To:        comp.protocols.tcp-ip
Subject:   TCP Window value

Hi,
	Can someone tell me if there is a standard way of finding
out the TCP Window value (the one in TCP header) in most UNIX hosts?

Thanks, 

shuenn hwang

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 92 01:54:00 GMT
From:      wangbs@casd1@casd1.iie.ncku
To:        comp.protocols.tcp-ip
Subject:   WANTED: tcp/ip development kit....


  Hi, all :
      Where can I find the tcp/ip development kit ? 
                Thanks for any reponse.
                                        wangbs@locust.iie.ncku.edu.tw
                                    or  wangbs@server2.iie.ncku.edu.tw

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 92 02:22:09 GMT
From:      jma@beach.cis.ufl.edu (John 'Vlad' Adams)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   Re: CSU/DSU that will accept V.25bis dialing commands?

Did jessea@u013.me.vp.com really type:
}  Anyone know of any CSU/DSUs that will accept V.25bis dialing commands?
}  We'd like to use switched digital lines between our locations, but our
}  routers (Telebit Netblazers) will only use V.25bis for dialing.  Anyone
}  know of such an animal?

Have you looked at the DataComm 500C/DBU-A?  We are using one of these
modems on a Wilten DDS and it has been a solid performer since
installed a month ago.

According to the manual it handles both the AT and V.25bis command
sets.

The company is General DataComm Inc.  Middlebury, Connecticut
06762-1299.
Their customer service number is 203-598-7526 between 0815 and 1700
EST.
-- 
Who:    John 'Vlad' Adams (squig) Scott Thurston Downtrodder III
Where:  jma@cis.ufl.edu     -or-      jadams@coral.senod.uwf.edu
Why:    But I was lonley, I was lost without my little black box
BBS:    The Beachside 1.904.492.2305 Pagan/Occult/Fido/IBM/Amiga

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1992 03:54:44 GMT
From:      broberts@wpi.WPI.EDU (broberts)
To:        comp.protocols.tcp-ip
Subject:   slip help.

I am hoping you can help me.

	We are looking for a good slip program to put into a MIPS type machine.

	The company I work for is looking to be able to use slip to dial into 
a machine and poll it for data.  If you know of a good slip program in C / C++
that we can use, or if you know a better place for me to ask, please send mail
to

	phm@concord.com

	Please do not reply to the user posting this message.

	I would appreciate any help you can give me.  
_____________________________________________________________________________

	Patrick H. Mullaney  - N1JEQ
	Systems Administrator
	Concord Communications		(508) 460-4646
	753 Forest St.			phm@concord.com
	Marlboro, MA  01752		n1jeq@concord.com

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 05:25:14 GMT
From:      alech@hpindda.cup.hp.com (Alec Henderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Need MIME Information

I wrote:

>Can anyone help me find information on MIME?
>
>Which RFC(s) is it defined in?
>Are there any other sources of information (descriptive articles, etc.)?

Many thanks to EVERYONE who responded.  I received a great deal of
helpful information.  I wasn't clear in my original post that I 
already know where and how to pull up RFCs (but was too lazy to
start there); thanks to all of you who sent me that information
also.

The net comes through again!

Regards,
Alec Henderson

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

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 92 06:50:46 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Re: Routing IP over X25

In article <1992Dec11.123440.17671@medusa.prime.com>
	davidh@CIS.Prime.COM (Dave Hill) writes:
>>I am having a problem routing IP packets over an X25 WAN using Sunlink
>>X25 version 7.0. The problem is as follows:-
>>Using the dynamic interface (std0) in Sunlink X25, I can connect to
>>hosts that have a different IP network number to my own interface, but I
>>cannot use those hosts as routers.

In article <1992Dec15.173348.24581@acc.com> art@acc.com (Art Berggreen) writes:
>Sorry, but fairly fundamental to IP routing, is the assumption that for two
>nodes to communicate directly, that they both have interfaces on a common IP
>(sub)network.

There are two different ways to productively view an X.25 interface in
an IP context:
(1) An interface to one IP network. All neighbors on that network are
    one hop away and the network is expected to be fully interconnected.
(2) A collection of (possibly unnumbered) point to point links.

Sun has two different X.25 products that implement the two strategies.

The first strategy is used in the product that Sun sells to the MILNET
market. This is especially useful in the MILNET context where there is
no need for table lookups, since there is an algorithmic equivalence
between IP addresses and X.25 addresses.

The second strategy is used in the commercial Sunlink X.25 product.

The point-to-point strategy needs an IP interface entity per neighbor.
You probably need to put the neighbor's IP address in the PEER field of
the interface data structure in order to allow routes though that peer.

I believe that ACC Systems has an external SCSI-attached X.25 box that
comes with drivers that will do the fully-connected subnet model of the
interface using commercial X.25 networks with table driven address
conversion.

-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 09:16:19 GMT
From:      ffritze@hpwad.WAD.HP.COM (Fromut Fritze)
To:        comp.protocols.tcp-ip
Subject:   WfWG over SLIP/PPP ???

I'm still busy to get WfWG's networking in sync with my requirements. 
The following pictures represent my understanding of driver interactions
(I put this here into that note, that you could please correct me, if I have
missconceptions about what's going on).
                                                                              
This is WfWG's regular setup using NetBeui:                                                                             
NDIS-driver --- MS_Netbeui ------ MS_WfWG                          

(BTW: Is this Netbeui layer contained in protman.dos or in workgroup.sys ?)

Although I've never been in touch with a Novell Network so far, configuring
Novell support in addition I get a picture like this:
                                                                              
              - Novell_to_NDIS -- Novell_App
             /    (MSIPX)                        
NDIS-driver /                             
            \                            
             \                                                        
              - MS_Netbeui ------ MS_WfWG                          

Again all stacks sit on top of the NDIS_driver. With some effort (didn't try
it so far) I might even get several packet aware applications working over
NDIS (using pkt_dis9.dos, pktmux.exe and pktdrv.exe):
                                                                              
                                                - Packet_Drv_1 -- Packet_App_1
                                               /                      
                                              /                       
              - Packet_to_NDIS -- Packet_Mux ----   ....       
             /                                \                      
NDIS-driver /                                  \                     
            \                                   - Packet_Drv_N -- Packet_App_2
             \                                                        
              - MS_Netbeui ------ MS_WfWG                          

But now what I'd like to have is NDIS through packet:

                            - Packet_Drv_1 ---- Packet_App_1
                           /    ...               
                          /                       
Packet_Drv -- Packet_Mux ---- Packet_Drv_N ---- Packet_App_2
                          \   
			   \
                            - NDIS_to_Packet -- MS_Netbeui -- MS_WfWG                          
This for instance would allow me to configure my PC at home to use a SLIP/PPP
packet driver (e.g. slip8250.com) to access my office. Therefor I search for a
NDIS_to_Packet driver.

Of cause hints/help to either

1.) configure WfWG to use packet drivers or
2.) get a SLIP/PPPdriver with NDIS interface

would be appreciated as well.
                                                                              
Thank you!

------------------------------------------------------------------------------
internet: ffritze@hpwbe007.wad.hp.com or ffritze@hpbbn.bbn.hp.com
phone:    Germany 7243 602296
address:  Fromut FRITZE, Waldbronn Analytic Division R&D,
	  Hewlett Packard Str, D 7517 Waldbronn 2, Germany
------------------------------------------------------------------------------

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 11:53:09 GMT
From:      amon@masi.ibp.fr (Amon Ettien)
To:        comp.protocols.tcp-ip
Subject:   measurement tool in public domain

I am looking for Measurement tools in the public domain. I am trying to
evaluate the performance of network software at the user level.

SOS for help

regards

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 13:44:23 GMT
From:      gmarzot@mitre.org (G. S. Marzot)
To:        comp.protocols.tcp-ip
Subject:   setting TCP parameters

Here is a question that I am sure has been asked before but no one I talk
to seems to know the answer. On a Sun Sparc 2 SunOS 4.1.X I would like to
set the default TCP window size to be as large as possible(32kbytes no ?).
Does anyone know a good source for this type of information.  I am working
on TCP over a satellite and I would also like to extend default time outs
to drop the TCP connection.  Does anyone know how to set this parameter as
well?  I assume it is in a header someplace and then I rebuild the kernel
but it would be nice to see the procedure written down before I start
flailing the system. Thanks in advance. -GSM

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1992 15:26:20 GMT
From:      wendy@sw.stratus.com (Wendy McNaughton)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI: t_accept returns TLOOK (why?)

> In article <1992Dec2.215556.25482@bnrmtl.bnr.ca> kenneth@bnr.ca (Ken Rosenfeld) writes:
> >I'm writing a server using the TLI library for TCP
> >(on a Sun).
> >
> >The server executes the following in a loop:
> >
> >  t_listen(listenfd, ...)        /* receive connect indication */
> >    
> >  t_accept(listenfd, newfd, ...) /* accept the call */
> >
> >There is a case where this code does not work: Two clients
> >make connect requests before the server executes the t_listen().
> >The t_listen() then receives the first connect indication.
> >The t_accept() fails, however, with t_errno = TLOOK.  
> >A subsequent call to t_look() returns the T_LISTEN event.
> >

I ran into the same situation here with our SVR4-based UNIX (FTX).
Our RPC implementation always assumes that if t_accept() fails
with t_errno = TLOOK, it is as a result of a disconnect (and therefore
calls t_rcvdis).  As Mat Cucuzella pointed out, this is consistent with
the examples in Stevens' UNIX Network Programming book.  I also found
similar examples in the AT&T SVR4 manuals.  

The consensus here seemed to be that this is incorrect behaviour for
t_accept.  It seems silly to interrupt one connection establishment
just to process another.  Since we have access to the sources, we were 
thinking of modifying our TLI library such that the t_accept call will 
not be interrupted by another connection request.  This seems to work 
well but was wondering if this is the proper thing to do. 

-- 
Wendy McNaughton		| wendy@sw.stratus.com              
Stratus Computer, Inc.		| Wendy_McNaughton@vos.stratus.com
55 Fairbanks Blvd.
Marlboro, MA  01752

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 92 15:58:02 GMT
From:      iversen@dsfys1.fi.uib.no (Per Steinar Iversen)
To:        comp.protocols.tcp-ip
Subject:   ********



Some days ago I asked in this group about LPD servers for PC-hardware.
A useable package seems to be the "NOS LPD - Line Printer Daemon" by
David E. Johnson (wotk!davidj@uunet.uu.net), release 1.2

I can nearly get this to work, as I can use things like TELNET and FTP
with this package, but it just refuses to accept input on port 515. As far
as I can see the PC have been setup as the manual describes... I have tried
mail to the author, but it bounces. Does anybody have any experience with this
package? Does it really work?

-psi

+------------------------------------------------------------------------------+
! Per Steinar Iversen    ! Internet:     iversen@vsfys1.fi.uib.no              !
! Fysisk Institutt       ! BITnet:       iversen@cernvm.bitnet                 !
! Universitetet i Bergen ! HEPnet:       VSFYS::IVERSEN (VSFYS=21.341=21845)   !
! Allegaten 55           ! Phone:       +47 5212770                            !
! N-5007 Bergen          ! Fax:         +47 5318334                            !
! NORWAY                 !                                                     !
+------------------------------------------------------------------------------+

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 16:03:51 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and ISDN / experiences with ISDN ?

Does anybody have any inputs on the use of ISDN links within
routed (IP, IPX etc.) networks?

I am looking into this on behalf of a large organisation with some 
60 or so campus's with big LANs, but only a few routers & bridges so far.

Is it sensible to have a multiply connected network? (i.e. with bits
dependent on an ISDN link for connectivity to other bits)?

Can ISDN links be used for load balancing or to handle peak
traffic only (say).

Is it feasible for ISDN call set-up to be automatic (i.e triggered by
some sequence of events in the router?

Which end of the link should make the call?

Must the ISDN destination number be fixed?  or can the router be
intelligent enough to dial a different number for different
circumstances, or dependent on the destination IP address?

We recognise that most routers on the market cannot do any of this yet,
but is there any likelihood of them being able to?  is it feasible?

Any ideas would be welcome...



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

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 16:37:27 GMT
From:      schiller@fzi.DE (Jochen Schiller)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: ATM


Hi,
first of all I think this is the appropriate newsgroup to talk about ATM.
ATM is the basic transport mechanism of B-ISDN and a I.xyz standard.

I can recommend the book:

Integrated Broadband Networks:
An Introduction to ATM-based Networks,
Rainer Haendel; Manfred Huber,
Addison-Wesley, 1991
(Electronic Systems Engeneering Series)

There are suppliers of ATM-cards, switches ... but:

  for example a ATM-switch costs about 50000$  (it's a SPARC with extra HW!)

So I don't know anything about cards for PC etc.

               Jochen Schiller

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 92 22:06:14
From:      nballou@lahaina.ColumbiaSC.NCR.COM (Nat Ballou)
To:        comp.protocols.tcp-ip,comp.windows.ms,comp.windows.x
Subject:   Re: TCP/IP and X under MS Windows 3.1?

In article <1992Dec16.232100.22980@alw.nih.gov> olds@helix.nih.gov (James Olds) writes:

   In article <+0d26sf@rpi.edu> act@sun.ipl.rpi.edu (just another programmer) writes:
   >I am very curious about people's experiences running TCP/IP software
   >under Win 3.1.  I am contemplating putting an Xserver onto a machine running 
   >Win 3.1 and connecting it to a Unix host to run Unix apps over the net.
   >
   >So  what kind of experiences have people had and/or recommendations.  I've only
   >just begun tis so if there is any recommended reading that would also be
   >appreciated.
   >


     I am running Integrated Inference's Machine's X11AT Xserver and it
     runs very well under both Win 3.0 and 3.1. My one complaint is that
     the icons for the X apps when Windoze is running as the manager (as
     opposed to say mwm or twm) are very boring and non-informational.
     The software is running on a 386/25 with 9MB Ram, 100 MB HD and
     a VGA card. The network card is a 3com 3c502 running PC/TCP as
     a network kernel. Hope that helps.>


I'm using a product from NCR called NCR Windows.  I work for NCR, but on
another software product.  This product is very stable, and has a nice desktop
option that supports drag and drop under MS Windows.  The product supports a
vareity of TCP/IP packages (Sun PC-NFS, Beame and Whiteside, FTP, etc.).  I'm
running with Wollongong Pathway 2.0.  The configuration of the TCP/IP package
is a bit of rocket science, especially getting things to load high, but this
really has nothing to do with the NCR Windows X server.

I'm typing this reply in under Gnus running in an emacs X window on a Sparc
displaying on my 33 MHz 486 PC running MS Windows 3.1.  I get very good
performance.

Cheers,

Nat

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 17:27:30 GMT
From:      GJAMES@HUSKY1.STMARYS.CA (GJames)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Engineer Certification (HOW? WHERE?)

In article <2480018@hprnd.rose.hp.com> k@hprnd.rose.hp.com (Steve Kao) writes:

>Ramon J. Hontanon:
>> Not long ago, I came across the term "Certified Network Engineer" in a
>> computing magazine (can't remember which one). My job includes a lot
>> of local networking, and I'm becoming very interested in such topics,
>> so I thought I'd tap the collective knowledge of this forum.
 
>You need to take an exam from Novell to become a CNE.  This means taking
>classes provided by Novell or from a Certified Novell Instructor (CNI).
>This will probably cost you big bucks, but you'll get a complete set of
>Novell manuals from taking the classes.
 
>Novell networking has very little to do with TCP/IP.
 
>- Steve Kao


You dont have to take any classes if you dont want to. But you do have to 
pass the exams.
From what I hear, the exams questions are right out of the workbooks so 
those who do take the classes are at a real advantage.

On a side note... I took the novell service and support course. Worst, most 
basic, waste of time, course I ever took. While on that course I had a lab 
partner who was about to get her CNE. If her level of knowledge is any 
indication of the value in novell's training, a CNE diploma isnt worth crap.
Of course it will get you a job, but still it's still crap.

IMHO

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 18:02:28 GMT
From:      aiko@opium.cs.odu.edu (John K Hayes)
To:        comp.databases.oracle,comp.sys.sun.misc,comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Need advice on accessing Oracle on a Sun LAN from a Novell LAN



A friend of mine is trying to figure out how to make an Oracle database
located on a Sun sparc (running SunOS with windows) accessible from nodes on a
Novell PC LAN.  I don't think he's bought anything yet; he just wants the 
configuration needed.  He wants to be able to run forms, etc from the PCs
while the database resides on the Suns using TCP/IP.  He's got some sort of
box called a xyplex that things plug into (not sure what that is) - he thinks
that DECNET is somehow involved with the xyplex (but again - I'm not sure).

The main problem is: how does he connect the Sun LAN to the Novell LAN
for Oracle communication.  I think Novell talks with IPX packets - would
he need some sort of IPX adapter?  I'm sure Oracle will run in both the
Sun and Novell environments - what packages does he need to connect them?
He said something about SQL*Net with SQL*Star for connecting - I don't 
know what SQL*Star is....

Any ideas on the hardware needed and software needed?  Thanks.

-- 
    ---{john hayes}  OLDOMINISITY; Norfolk, Virginia USA
                     internet: aiko@cs.odu.edu

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 92 23:12:39
From:      sung@novi.auc.dk (Mads Sung Bak Jensen)
To:        comp.protocols.tcp-ip
Subject:   Looking for integrated mail-ftp-telnet-client for dos



HI there.... 
The subject sais it all..

I am looking for what you think is the best PD mail-,ftp- and telnet
client for Dos.

If you have experiences with such an application, then please
email 
     sung@novi.auc.dk
and tell me where to get it.....

Thanks in advance...

/// Mads ///


-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 18:34:46 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Routing IP over X25


In article <1992Dec11.123440.17671@medusa.prime.com> davidh@CIS.Prime.COM writes:

>route add net yy.yy.2.0 yy.yy.1.1 1
>
>to which route says "network is unreachable". This is because the kernel
>routing code states that the router must be on the SAME network as your
>interface. 


Hhmmm.. dunno about that last comment...

Dave,

Unless I've misread your explanation, I think the problem lies in your
calling the third host yy.yy.2.0  Because if it is on a separate subnet
from yy.yy.1.1 then its interface must have a different network address.
In your set up I think you're violating IP addressing rules..(?)

If this is the case, you will need to define the output port of the second
host yy.yz.1.1 and the input port of the third (last) host yy.yz.1.2

I.e. if the second and third hosts are joined by a subnetwork, then they 
must have a common subnet number  (yy.yz).

It's easy to forget that in routing the IP address defines the interface
of a router or host, not the actual router.  I.e. a host acting as a router
must have one address for each interface it supports... and the network
number part (in your case the first two octets, as you're Class B).

I hope this helps.

Forgive me if I've given you duff info.   

Regards,



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

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 18:54:40 GMT
From:      matt@wardsgi.med.yale.edu (Matt Healy)
To:        comp.protocols.tcp-ip
Subject:   Re: setting TCP parameters

In article <gmarzot-161292084738@gmarzot.mitre.org>, gmarzot@mitre.org (G.
S. Marzot) wrote:
> 
> Here is a question that I am sure has been asked before but no one I talk
> to seems to know the answer. On a Sun Sparc 2 SunOS 4.1.X I would like to
> set the default TCP window size to be as large as possible(32kbytes no ?).
> Does anyone know a good source for this type of information.  I am working
> on TCP over a satellite and I would also like to extend default time outs
> to drop the TCP connection.  Does anyone know how to set this parameter as
> well?  I assume it is in a header someplace and then I rebuild the kernel
> but it would be nice to see the procedure written down before I start
> flailing the system. Thanks in advance. -GSM

I don't know about Suns; as you can tell from my address I am on a
Silicon Graphics workstation myself.  On SGIs, you change the parameters
in various header files and then run the command "autoconfig" to
reconfigure
the kernel via lboot.  On my machine the various files live in the
directory /usr/sysgen/master.d/* with fairly intuitive filenames and
they are heavily commented.  Look for files called README or something
similar in your /usr/sysgen/* directory tree.

I just did [grep "tcp" /usr/sysgen/master.d/*] on my sgi:

----------------------------output follows---------
wardsgi 42% grep "tcp" /usr/sysgen/master.d/*
/usr/sysgen/master.d/bsd:int tcpprintfs  = 0;
/usr/sysgen/master.d/bsd:unsigned 
long tcp_sendspace = 60 * 1024;       /* must be < 64K */
/usr/sysgen/master.d/bsd:unsigned 
long tcp_recvspace = 60 * 1024;       /* must be < 64K */
/usr/sysgen/master.d/bsd:int tcp_ttl = 60;
/usr/sysgen/master.d/master.c:int tcpprintfs  = 0;
/usr/sysgen/master.d/master.c:unsigned 
long tcp_sendspace = 60 * 1024;  /* must be < 64K */
/usr/sysgen/master.d/master.c:unsigned 
long tcp_recvspace = 60 * 1024;  /* must be < 64K */
/usr/sysgen/master.d/master.c:int tcp_ttl = 60;
wardsgi 43%
-------------------end of output------------

Matt Healy
"I pretend to be a network administrator;
 the lab net pretends to work"

matt@wardsgi.med.yale.edu

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 19:12:01 GMT
From:      ronf@panther3.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI: t_accept returns TLOOK (why?)

testing
-- 

>
Ron Feigen
ronf@panther.mot.com

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 21:22:14 GMT
From:      scottm@cscns.com (Scott McKinsey)
To:        comp.windows.x,comp.windows.ms,comp.protocols.tcp-ip
Subject:   Re: TCP/IP and X under MS Windows 3.1?

act@sun.ipl.rpi.edu (just another programmer) writes:
: I am very curious about people's experiences running TCP/IP software
: under Win 3.1.  I am contemplating putting an Xserver onto a machine running 
: Win 3.1 and connecting it to a Unix host to run Unix apps over the net.
: 
: So  what kind of experiences have people had and/or recommendations.  I've only
: just begun tis so if there is any recommended reading that would also be
: appreciated.
: 
: Thanks
: Grant
ditto

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1992 21:54:44 GMT
From:      p228@uni05.larc.nasa.gov (Bailey Bob)
To:        comp.databases.oracle,comp.sys.sun.misc,comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Need advice on accessing Oracle on a Sun LAN from a Novell LAN

In article <1992Dec16.180228.16213@cs.odu.edu> aiko@opium.cs.odu.edu (John K Hayes) writes:
>
>
>A friend of mine is trying to figure out how to make an Oracle database
>located on a Sun sparc (running SunOS with windows) accessible from nodes on a
> ....
>The main problem is: how does he connect the Sun LAN to the Novell LAN
>for Oracle communication.  I think Novell talks with IPX packets - would
>he need some sort of IPX adapter?  I'm sure Oracle will run in both the
>Sun and Novell environments - what packages does he need to connect them?
>He said something about SQL*Net with SQL*Star for connecting - I don't 
>know what SQL*Star is....
>
>Any ideas on the hardware needed and software needed?  Thanks.
>

I'm not sure about the hardware, but at our site, run Novell on the PCs
with the Novell TCP/IP support.  This allows us to run our ethernet and
have access to both the Novell server and to also access any of several
DEC/Oracle servers.




-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1992 22:57:09 GMT
From:      kevin@kevins.frontiertech.com
To:        comp.protocols.tcp-ip
Subject:   Price of Apple TCP/IP

It's my understanding TCP used to be free from Apple.
Is this still the case, or are they charging for it now.

Any help would be appreciated!

Kevin@Kevins.FrontierTech.Com

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 1992 23:21:00 GMT
From:      olds@helix.nih.gov (James Olds)
To:        comp.windows.x,comp.windows.ms,comp.protocols.tcp-ip
Subject:   Re: TCP/IP and X under MS Windows 3.1?

In article <+0d26sf@rpi.edu> act@sun.ipl.rpi.edu (just another programmer) writes:
>I am very curious about people's experiences running TCP/IP software
>under Win 3.1.  I am contemplating putting an Xserver onto a machine running 
>Win 3.1 and connecting it to a Unix host to run Unix apps over the net.
>
>So  what kind of experiences have people had and/or recommendations.  I've only
>just begun tis so if there is any recommended reading that would also be
>appreciated.
>

  
  I am running Integrated Inference's Machine's X11AT Xserver and it
  runs very well under both Win 3.0 and 3.1. My one complaint is that
  the icons for the X apps when Windoze is running as the manager (as
  opposed to say mwm or twm) are very boring and non-informational.
  The software is running on a 386/25 with 9MB Ram, 100 MB HD and
  a VGA card. The network card is a 3com 3c502 running PC/TCP as
  a network kernel. Hope that helps.>


--
****************************************************************************
* James L. Olds Ph.D.                 Neural Systems Section               *
* domain: olds@helix.nih.gov           NINDS, NIH, Bethesda, MD. 20892 USA *
****************************************************************************

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 1992 03:15:17 GMT
From:      randy@ve6bc.ampr.ab.ca (Randy Pointkoski)
To:        comp.protocols.tcp-ip
Subject:   Wanted:SPARC (or Bugd.look-a-like)

we are setting up a test of data compression equipment and we need
something SPARC'y to load down the link

-- 


Randy J. Pointkoski P.Eng.                       tel: (403) 437-5961
Edmonton, Alberta, Canada                        fax: (403) 436-1686

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 1992 03:43:27 GMT
From:      Steve.Bauer@launchpad.unc.edu (Steve Bauer)
To:        comp.protocols.tcp-ip
Subject:   rarp server deamon

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 1992 08:02:26 GMT
From:      erik@eab.retix.com (Erik Forsberg)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI: t_accept returns TLOOK (why?)

In article <1gnhqsINN1d2@transfer.stratus.com> wendy@sw.stratus.com (Wendy McNaughton) writes:
>> In article <1992Dec2.215556.25482@bnrmtl.bnr.ca> kenneth@bnr.ca (Ken Rosenfeld) writes:
>> >I'm writing a server using the TLI library for TCP
>> >(on a Sun).
>> >
>> >The server executes the following in a loop:
>> >
>> >  t_listen(listenfd, ...)        /* receive connect indication */
>> >    
>> >  t_accept(listenfd, newfd, ...) /* accept the call */
>> >
>> >There is a case where this code does not work: Two clients
>> >make connect requests before the server executes the t_listen().
>> >The t_listen() then receives the first connect indication.
>> >The t_accept() fails, however, with t_errno = TLOOK.  
>> >A subsequent call to t_look() returns the T_LISTEN event.
>> >
>
>I ran into the same situation here with our SVR4-based UNIX (FTX).
>Our RPC implementation always assumes that if t_accept() fails
>with t_errno = TLOOK, it is as a result of a disconnect (and therefore
>calls t_rcvdis).  As Mat Cucuzella pointed out, this is consistent with
>the examples in Stevens' UNIX Network Programming book.  I also found
>similar examples in the AT&T SVR4 manuals.  
>
>The consensus here seemed to be that this is incorrect behaviour for
>t_accept.  It seems silly to interrupt one connection establishment
>just to process another.  Since we have access to the sources, we were 
>thinking of modifying our TLI library such that the t_accept call will 
>not be interrupted by another connection request.  This seems to work 
>well but was wondering if this is the proper thing to do. 
>

The MOST proper thing to do is changing TPI implementations to always
returning a qlen of 1 to the TLI library on the T_BIND_ACK response
message but internally queue up incoming connect indication upto
whatever limit you feel like (the original qlen may be a good number).

This avoids that not so cleverly written TLI applications still work
even if they get several connect indications at the same time and still
being able to handle this.

To simplify what I just said, the net effect is that the TPI Streams
driver itself queues many incoming connect indications, but they are
presented one at a time to the TLI user. That way the t_look() error
will never happen (unless it REALLY IS a disconnect indication).

All Retix TPI Streams driver operates that way.


-- 
---------------------------------------------------------------------------
Erik Forsberg, erik@eab.retix.com Phone: (310) 476-7133 FAX: (310) 476-7657

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 1992 16:41:55
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: RAW SPEED numbers for various TCP-IP implementations

In article <92345.230225FFAAC09@cc1.kuleuven.ac.be> Paul Bijnens <FFAAC09@cc1.kuleuven.ac.be> writes:

    There are normally 5 buffers in my PC/TCP-implementation.

With 5 buffers, I usually set my TCP window to 4096.  I don't recommend
specifying a low-window - the value we pick automatically is reasonable
and other values may provoke more problems than they solve.
    
    Yes, the Compac and the PC are connected with a Vines network on
    ARCNET.  ARCNET is 2.5 Mbit/sec, and has not much problem to get
    effectively about 2.5 Mbit/sec throughput out of it (measured using
    the dos command "copy" to just copy a file across the cable).  So
    I doubt Vines is the guilty party.

With the small TCP windows you're using, the round-trip-time through the
routers will dominate transmission speed.  Still, if Ascii transfers are
notably slower than Binary, a slight difference in timing is probably
provoking a pathological condition.  In INET DEBUG, check for errors
and "out of buffers" conditions.  In INET STAT, check both "rexmits"
and "duplicate packets".  In INET TCP, see what the round trip time
for the connection is (you can get this while shell-escaped).

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


-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 92 13:37:36 GMT
From:      kiron@vedge.com (Kiron D. Bondale)
To:        comp.windows.x,comp.windows.ms,comp.protocols.tcp-ip
Subject:   Re: TCP/IP and X under MS Windows 3.1?

We have been using NCD's PC-Xview software for the last few months, and
have had a lot of success with it.  It unfortunately does not support
PD TCP packages but if you are running something like FTP's PC-TCP or
PC-NFS, it works like a charm.  One of our users liked it enough that he
gave up his X-Station in favour of using his 486.

Kiron

-----------------------------------------------------------------------
+ Kiron D. Bondale     + "Age is a matter of the mind.  If you don't  +
+ Systems Manager      +    mind, it doesn't matter."... Mark Twain   +
-----------------------------------------------------------------------
+ Visual Edge Software Ltd +  3870 Cote Vertu, St. Laurent, Quebec,   +
+ kiron@vedge.com          +  CANADA, H4R 1V4  Tel: (514)-332-6430    +
-----------------------------------------------------------------------
-- 
-----------------------------------------------------------------------
+ Kiron D. Bondale     + "Age is a matter of the mind.  If you don't  +
+ Systems Manager      +    mind, it doesn't matter."... Mark Twain   +
-----------------------------------------------------------------------

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 1992 16:12:35 GMT
From:      gong@jazz.concert.net (Fengmin Gong)
To:        comp.protocols.tcp-ip
Subject:   Two papers (error control and flow control) available for ftp

Hello everyone,

Two papers based on my D.Sc. work at Washington U. are now available
for anonymous ftp from "ftp.concert.net".  The compressed PS files
are /pub/error_ctl.ps.Z and /pub/flow_ctl.ps.Z.  The papers present
design, simple analysis, and simulation of a new error control and a flow
control scheme for supporting demanding applications in high-speed
environments.  The work has been done under the supervision of Guru
Parulkar.  Two abstracts are attached below.  Comments are all welcome
and should be addressed to "gong@concert.net".

Thanks,

Fengmin Gong
MCNC Communications Research

------------------
TITLE:
     An Application-Oriented Error Control Scheme For High Speed Networks

ABSTRACT:
Many new network applications demand interprocess communication (IPC)
services that are not supported by existing transport protocol mechanisms.
Large bandwidth-delay products of high-speed networks also render
the existing error control mechanisms inefficient. This paper
presents the design, evaluation, and 
implementation of an application-oriented error control scheme that can
support efficient IPC for these applications in high-speed network
environments.


TITLE:
    A Two-Level Flow Control Scheme For High Speed Networks

ABSTRACT:
Many new network applications demand interprocess communication (IPC)
services with guaranteed bandwidth, delay, and loss. Existing transport
protocol mechanisms have not been designed with these service objectives.
Large bandwidth-delay products of high-speed networks also render
the existing flow control mechanisms inefficient. This paper
presents the design, evaluation, and 
implementation of a two-level flow control scheme that can
support efficient IPC for these applications in high-speed network
environments.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1992 17:21:12 GMT
From:      C_S02254@CONRAD.APPSTATE.EDU (Jon C Austin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Window value

In <8697.17794@stratus.SWDC.Stratus.COM> shuenn@tora.swdc.stratus.com writes:

> Hi,
> 	Can someone tell me if there is a standard way of finding
> out the TCP Window value (the one in TCP header) in most UNIX hosts?
> 
> Thanks, 
> 
> shuenn hwang

Under AIX, I've been able to get lots of stats about the TCP and IP
process with a command no(network options).  

Try:
	" no -a" 
and see if you see anything.

Jon Austin
Appalachian State University
Boone, NC


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 92 19:48:26 GMT
From:      sjs@netcom.com (Stephen Schow)
To:        comp.protocols.tcp-ip
Subject:   Need remsh for Mac

There exists on our UNIX box a command called remsh that sends a remote shell
command to a remote machine via tcp/ip.  Anyone know of something that uses
MacTCP to do the same thing?  I would like to be able to select from a list
of scripts, or even just double click on an icon, which would send the 
remsh command to the host.

I suspect that nothing is out there to do this, which means I'm gonna have
to write it myself, but I have very little Mac programming g experience,
so I hope something is already out there.

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

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 1992 20:00:39 GMT
From:      news@massey.ac.nz (USENET News System)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for integrated mail-ftp-telnet-client for dos

In article <SUNG.92Dec16231239@novi.novi.auc.dk> sung@novi.auc.dk (Mads Sung Bak Jensen) writes:
>Path: cc-server4.massey.ac.nz!comp.vuw.ac.nz!waikato.ac.nz!decwrl!olivea!uunet!mcsun!sunic!dkuug!iesd.auc.dk!news.iesd.auc.dk!sung
>Newsgroups: comp.protocols.tcp-ip
>Subject: Looking for integrated mail-ftp-telnet-client for dos
>Message-ID: <SUNG.92Dec16231239@novi.novi.auc.dk>
>From: sung@novi.auc.dk (Mads Sung Bak Jensen)
>Date: 17 Dec 92 07:12:39 GMT
>Sender: news@iesd.auc.dk (UseNet News)
>Distribution: comp
>Organization: NOVI, Nordjyllands Videnpark A/S
>Lines: 16



>HI there.... 
>The subject sais it all..
 
>I am looking for what you think is the best PD mail-,ftp- and telnet
>client for Dos.
 
>If you have experiences with such an application, then please
>email 
>     sung@novi.auc.dk
>and tell me where to get it.....
 
>Thanks in advance...
 
>/// Mads ///
NUPOP - pop mail client for the PC! It also does Gopher, Finger, Webster and 
name-lookup! The author has just added the ftp and telnet features to 
version 1.1 (alpha), so they are still a bit rough, but its a great mail 
reader and the next test version of it will be here RSN (real son now).

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 1992 20:09:48 GMT
From:      news@massey.ac.nz (USENET News System)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for integrated mail-ftp-telnet-client for dos

In article <bphillip.28.724622439@massey.ac.nz> news@massey.ac.nz (USENET News System) writes:
>Newsgroups: comp.protocols.tcp-ip
>Path: cc-server4.massey.ac.nz!massey.ac.nz!bphillip
>From: news@massey.ac.nz (USENET News System)
>Subject: Re: Looking for integrated mail-ftp-telnet-client for dos
>Message-ID: <bphillip.28.724622439@massey.ac.nz>
>Organization: School of Maths and Info Sciences, Massey University, NZ.
>References: <SUNG.92Dec16231239@novi.novi.auc.dk>
>Date: Thu, 17 Dec 1992 20:00:39 GMT
 
>In article <SUNG.92Dec16231239@novi.novi.auc.dk> sung@novi.auc.dk (Mads Sung Bak Jensen) writes:
>>Path: cc-server4.massey.ac.nz!comp.vuw.ac.nz!waikato.ac.nz!decwrl!olivea!uunet!mcsun!sunic!dkuug!iesd.auc.dk!news.iesd.auc.dk!sung
>>Newsgroups: comp.protocols.tcp-ip
>>Subject: Looking for integrated mail-ftp-telnet-client for dos
>>Message-ID: <SUNG.92Dec16231239@novi.novi.auc.dk>
>>From: sung@novi.auc.dk (Mads Sung Bak Jensen)
>>Date: 17 Dec 92 07:12:39 GMT
>>Sender: news@iesd.auc.dk (UseNet News)
>>Distribution: comp
>>Organization: NOVI, Nordjyllands Videnpark A/S
>>Lines: 16



>>HI there.... 
>>The subject sais it all..
 
>>I am looking for what you think is the best PD mail-,ftp- and telnet
>>client for Dos.
 
>>If you have experiences with such an application, then please
>>email 
>>     sung@novi.auc.dk
>>and tell me where to get it.....
 
>>Thanks in advance...
 
>>/// Mads ///
>NUPOP - pop mail client for the PC! It also does Gopher, Finger, Webster and 
>name-lookup! The author has just added the ftp and telnet features to 
>version 1.1 (alpha), so they are still a bit rough, but its a great mail 
>reader and the next test version of it will be here RSN (real son now).

I wish my News reader would pick a diferent key combo to post with!!:)
You can get NUPop from ftp.acns.nwu.edu ( NorthWestern University)

Brenden
B.C.Phillips@massey.ac.nz
Computer Consultant
School of Maths and Info Sciences
Massey University
Palmerston North
New Zealand
"Du t Gvrnmnt bggt cts ths sgntr hs bn thrgh lssy cmprssn"

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1992 20:42:07 GMT
From:      pjinkila@thunder.LakeheadU.Ca (Paul Inkila)
To:        comp.protocols.tcp-ip
Subject:   How to tell MacTCP to use BOOTP or RARP?

How does one tell MacTCP to user BOOTP or RARP for address resolution?

I recently added a new IP net to our network, and want to use BOOTP.
(Since it's routable thru our router). PC's using BOOTP on this new segment
work fine. i.e. they are able to access a BOOTP database on the other
side of the router.  But no go for the Mac's.  Any pointers?

Thanx.

Paul Inkila		pjinkila@thunder.lakeheadu.ca
Lakehead U

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 92 21:33:50 GMT
From:      shuenn@tora.swdc.stratus.com (serene2)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: ATM

Whoever is interested in ATM should go to another news group,

comp.dcom.cell-relay

-shuenn

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 92 23:02:14 GMT
From:      tbo@vector.dallas.tx.us (Terry Bohaning)
To:        comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Limiting Telnet access.

I've recently become very concerned about the security of many of 
the Unix workstations under my care. Some of the users are overly
free with their passwords and I would really like to limit access
to the systems.

Has anyone modified the telnet daemon to include to capability
for an allow/deny file. What I'm thinking of is a way to prevent
any machine not listed in an allow file or every machine except
those listed in a deny file from telneting into our machines.

I've gotten the BSD Net 2 sources and have started looking at them,
but wondered if anyone else has already tried this yet.

Your comments please......

Terry Bohaning			tbo@vector.dallas.tx.us

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 1992 11:21:35 -0600
From:      mgriffin@matt.ksu.ksu.edu (Mark Griffin)
To:        comp.protocols.tcp-ip
Subject:   Simultaneous TCP/IP and Lan Manager

Is there a version of TCP/IP that will run basically simultaneous with
Starlan's Lan Manager?  
-- 
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  .
Mark Griffin, Sys Admin, Fort Hays State University      |It is always better to
Internet:mgriffin@matt.ksu.ksu.edu Bitnet:mgriffin@ksuvm |do, than be done to.
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .  .

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 92 04:21:30 GMT
From:      todd@draco.macsch.com (Todd C. Williams)
To:        comp.protocols.tcp-ip
Subject:   subnets of net A separated by net B?

Can I have two subnets physically separated by a different net?

Let's say net A is 150.150, with subnets A1=150.150.10 and A2=150.150.20
and net B is 75.  I have a bunch of hosts running RIP, and some CISCOs:

----A1-----(CISCO)..(CISCO)========B==========(CISCO)-------A2------

The reason I'm doing this is that I'm changing the whole network from
the B address to subnets of the A address.  The Ciscos communicate
via IGRP and redistribute RIP.  All hosts run routed in quiet mode.

The Cisco manual talks about using secondary addresses to accomplish
this (I think), but their example is pitiful.

I attempted to give the CISCO interfaces on net B secondary addresses
that conform to the A network.  It didn't work.

The biggest problem, (maybe), is that the routing tables of the hosts
on net B list the A network and NOT the A1 and A2 subnets.  (Currently
all but the A2 subnet is in place).

Any hints would be appreciated.

-- 
Todd Williams    UNIX Systems Coordinator     todd@macsch.com    (213) 259-4973
MacNeal-Schwendler Corp. ("MSC"),  815 Colorado Blvd.,  Los Angeles, CA   90041
>> "Solaris 2.0 --- It's enough to make you leave the company." -Rob Kolstad <<

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 1992 08:00:16 GMT
From:      Jan.vOorschot@dnpap.et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.tcp-ip
Subject:   ipmulti for SUNOS 4.1.3

Hi,

As the title says, i'am looking for ipmulti for SUNOS 4.1.3.
The standard distribution 

	'ipmulti-sunos41x.tar.Z'
	
contains kernel patches for SUNOS 4.1.1 and SUNOS4.1.2, but ...., not
for SUNOS4.1.3.
Since i'am not much of a Unix kernel patcher myself, i would like 
to make use of the work of some kind patcher out there.

Any help will sure be appreciated,

Jan


-- 
-- Ir. Jan van Oorschot.      --- Email: Jan.vOorschot@dnpap.et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
--
-- Ir. Jan van Oorschot.      --- Email: Jan.vOorschot@dnpap.et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 1992 08:06:59 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: subnets of net A separated by net B?

In article <1992Dec18.042130.8184@draco.macsch.com> todd@draco.macsch.com (Todd C. Williams) writes:

    Can I have two subnets physically separated by a different net?
Yes.    
    Let's say net A is 150.150, with subnets A1=150.150.10 and A2=150.150.20
    and net B is 75.  I have a bunch of hosts running RIP, and some CISCOs:
    
    ----A1-----(CISCO)..(CISCO)========B==========(CISCO)-------A2------
    
    The reason I'm doing this is that I'm changing the whole network from
    the B address to subnets of the A address.  The Ciscos communicate
    via IGRP and redistribute RIP.  All hosts run routed in quiet mode.
    
    The Cisco manual talks about using secondary addresses to accomplish
    this (I think), but their example is pitiful.
Sorry.  We've tried to fix this in later versions.  In any case, what you
want to do is to make A3=150.150.30 be the same a cable B.    

    I attempted to give the CISCO interfaces on net B secondary addresses
    that conform to the A network.  It didn't work.
What (exactly) did you do?
    
    The biggest problem, (maybe), is that the routing tables of the hosts
    on net B list the A network and NOT the A1 and A2 subnets.  (Currently
    all but the A2 subnet is in place).
The hosts shouldn't really care as long as it points to a router with good
routes. 

-- 
abyss \*-'bis\ n 
  1 : the bottomless gulf, pit, or chaos of the old cosmogonies  2 a : an 
  immeasurably deep gulf or great space  b : intellectual or spiritual 
  profundity; also : vast moral depravity 3 a Border Intermediate System

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 92 12:00:32 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: ATM



 >First , is this an appropriate newgroup to talk about ATM networks?

no
try
comp.dcom.cell-relay

 jon


-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 1992 20:58:44 -0500
From:      dean@deans.frontiertech.com
To:        news.announce.newgroups,news.groups,comp.os.ms-windows.apps,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.win32,comp.os.os2.networking,comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   RFD: comp.os.ms-windows.networking

This is a formal Request For Discussion regarding the establishment of
a newsgroup to discuss issues and questions related to Windows
networking.

This announcement is cross-posted to newsgroups whose readers may have
interest in the discussion about the new group. Follow-up discussion
will take place in "news.groups". Comments may be emailed to me at 

dean@deans.frontiertech.com
192.104.32.49

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

NEWSGROUP

  comp.os.ms-windows.networking 

RATIONALE

  Networking in the Microsoft Windows environment has witnessed
  explosive growth in recent times, creating a broad base of computer
  users who need relevant and timely information in order to keep pace
  with the many new developments.  The advent of new networking
  technologies and standards, such as Windows NT and Windows Sockets,
  makes the need for information more pressing than ever before.

  The newsgroup would feature discussions on new developments and
  products in the networking industry, as well as information on
  existing and emerging standards and issues. Topics could include
  TCP/IP, OSI/GOSIP, X.25, NFS, FTP, SMTP, POP, X.400, FTAM, SNMP,
  Terminal Emulation, Network Printing, NetBIOS, SLIP, PPP, Windows
  Sockets API, Windows NT, and more.

  The newsgroup would provide an invaluable resource for everyone
  interested in learning more about the rapidly growing field of
  Windows networking as well as the various issues related to LAN and
  WAN networking. Creation of the newsgroup would reduce the traffic
  in comp.os.ms-windows.apps and comp.os.ms-windows.advocacy, which
  frequently have networking questions and issues. Creation of the
  windows networking newsgroup would be analogous to comp.os.os2.networking.

NEWSGROUP CREATION

Please post all discussion to news.groups.

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 1992 15:37:15 GMT
From:      vwelch@ncsa.uiuc.edu (Von Welch)
To:        comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Re: Limiting Telnet access.

In article <1992Dec17.230214.16501@vector.dallas.tx.us>, tbo@vector.dallas.tx.us (Terry Bohaning) writes:
|> Has anyone modified the telnet daemon to include to capability
|> for an allow/deny file. What I'm thinking of is a way to prevent
|> any machine not listed in an allow file or every machine except
|> those listed in a deny file from telneting into our machines.

Look for a program called tcpwrapper. It does just what you are looking for.

-- 
Von Welch (vwelch@ncsa.uiuc.edu)	NCSA Networking Development Group

- I speak only for myself and those who think exactly like me -

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 92 17:13:08 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip
Subject:   TLI t_accept behavior (was TLI: t_accept returns TLOOK (why?))

In article <1992Dec17.080226.3572@eab.retix.com>, erik@eab.retix.com (Erik Forsberg) writes:
|> In article <1gnhqsINN1d2@transfer.stratus.com> wendy@sw.stratus.com (Wendy McNaughton) writes:
|> >> In article <1992Dec2.215556.25482@bnrmtl.bnr.ca> kenneth@bnr.ca (Ken Rosenfeld) writes:
|> >> >I'm writing a server using the TLI library for TCP
|> >> >(on a Sun).
|> >> >
|> >> >The server executes the following in a loop:
|> >> >
|> >> >  t_listen(listenfd, ...)        /* receive connect indication */
|> >> >    
|> >> >  t_accept(listenfd, newfd, ...) /* accept the call */
|> >> >
|> >> >There is a case where this code does not work: Two clients
|> >> >make connect requests before the server executes the t_listen().
|> >> >The t_listen() then receives the first connect indication.
|> >> >The t_accept() fails, however, with t_errno = TLOOK.  
|> >> >A subsequent call to t_look() returns the T_LISTEN event.
|> >> >
|> >
|> >I ran into the same situation here with our SVR4-based UNIX (FTX).
|> >Our RPC implementation always assumes that if t_accept() fails
|> >with t_errno = TLOOK, it is as a result of a disconnect (and therefore
|> >calls t_rcvdis).  As Mat Cucuzella pointed out, this is consistent with
|> >the examples in Stevens' UNIX Network Programming book.  I also found
|> >similar examples in the AT&T SVR4 manuals.  
|> >
|> >The consensus here seemed to be that this is incorrect behaviour for
|> >t_accept.  It seems silly to interrupt one connection establishment
|> >just to process another.  Since we have access to the sources, we were 
|> >thinking of modifying our TLI library such that the t_accept call will 
|> >not be interrupted by another connection request.  This seems to work 
|> >well but was wondering if this is the proper thing to do. 
|> >
|> 
|> The MOST proper thing to do is changing TPI implementations to always
|> returning a qlen of 1 to the TLI library on the T_BIND_ACK response
|> message but internally queue up incoming connect indication upto
|> whatever limit you feel like (the original qlen may be a good number).
|> 
|> This avoids that not so cleverly written TLI applications still work
|> even if they get several connect indications at the same time and still
|> being able to handle this.
|> 
|> To simplify what I just said, the net effect is that the TPI Streams
|> driver itself queues many incoming connect indications, but they are
|> presented one at a time to the TLI user. That way the t_look() error
|> will never happen (unless it REALLY IS a disconnect indication).

That will work for most TLI clients.  Unfortunately, SVVS is not like most
TLI clients and could score the TPI provider as non-compliant (that is if
USL ever got around to writing a provider test that wasn't full of false
assumptions).

|> 
|> All Retix TPI Streams driver operates that way.
|> 
|> 
|> -- 
|> ---------------------------------------------------------------------------
|> Erik Forsberg, erik@eab.retix.com Phone: (310) 476-7133 FAX: (310) 476-7657

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


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 92 18:10:05 GMT
From:      matt@gecko.oes.orst.edu (Matt Curfman)
To:        comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Re: Limiting Telnet access.

In article <1992Dec17.230214.16501@vector.dallas.tx.us> tbo@vector.dallas.tx.us (Terry Bohaning) writes:
>I've recently become very concerned about the security of many of 
>the Unix workstations under my care. Some of the users are overly
>free with their passwords and I would really like to limit access
>to the systems.
>
>Has anyone modified the telnet daemon to include to capability
>for an allow/deny file. What I'm thinking of is a way to prevent
>any machine not listed in an allow file or every machine except
>those listed in a deny file from telneting into our machines.
>
>I've gotten the BSD Net 2 sources and have started looking at them,
>but wondered if anyone else has already tried this yet.
>
>Your comments please......
>
>Terry Bohaning			tbo@vector.dallas.tx.us

I have installed on my 386bsd machine a package called wrapper.  From the
Readme:

                                --o--

This package provides a couple of tiny programs that monitor incoming
requests for IP services such as TFTP, EXEC, FTP, RSH, TELNET, RLOGIN,
FINGER, SYSTAT, and many others.
 
Optional features are: access control based on pattern matching; remote
username lookup using the RFC 931 protocol; protection against rsh and
rlogin attacks from hosts that pretend to have someone elses name.
<deleted>
        Wietse Venema (wietse@wzv.win.tue.nl),
        Department of Mathematics and Computing Science,
        Eindhoven University of Technology,
        The Netherlands.

                                --o--

I have placed a copy of wrapper.tar.Z on anonymous ftp at oes.orst.edu in
/pub/386bsd/wrapper.tar.Z.  There are many other sites for this software 
as well.

-mc
_____________________________________________________________________________
Matt Curfman                                    Almanac Information Archivist 
matt@gecko.oes.orst.edu                     Oregon State University Extension

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 1992 20:32:53 GMT
From:      alech@hpindda.cup.hp.com (Alec Henderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Need MIME Information

I wrote:

>Can anyone help me find information on MIME?
>
>Which RFC(s) is it defined in?
>Are there any other sources of information (descriptive articles, etc.)?

After thanking everyone who responded, someone has asked me to pass along
what I learned.  I did not intend to take this conversation "off-line",
so here is a quick summary.  Nothing earth-shattering, I suspect, but
good to know nonetheless!

1.  MIME is defined in RFCs 1341-1344.

2.  There is a good introductory article on MIME in the September
    1992 issue of Connexions; also several other interesting articles
    on e-mail, both MIME and X.400.  (Ole Jacobsen, the Connexions
    editor, was kind enough to send me a copy of the September issue.)

3.  There is a freely distributable package that helps implement some of
    the MIME mechanisms.  The package is called "metamail" and is
    available for anonymous ftp from thumper.bellcore.com.  

4.  Discussions of MIME standards development and implementers hang out
    on the IETF MIME Working Group mailing list.

5.  More general discussions of MIME take place on USENET in comp.mail.mime,
    which was recently created.

Again, thanks to everyone for all the helpful information. 

Regards,
Alec Henderson

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

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Dec 1992 02:18:46 GMT
From:      wayne@kean.ucs.mun.ca
To:        comp.protocols.tcp-ip
Subject:   PCS AND DUPLICATE TCP ADDRESSES

I am using CMU TCP on a VAX running VMS. I am telneting to this vax from 
PC's using Kermit 3.11 ( which has built-in telnet ).

Many times pc users copy the kermit file from their pc around to other 
machines. One of the files they copy is mskermit.ini that has the tcp 
address of the person's pc. When that file is copied, the receiving machine 
also gets the tcp address of the copying machine. And on it goes. Sometimes 
a whole lab of pc's gets the same tcp address. The network dies a slow 
death.

My question is " Is there a way to prevent a pc from accessing the network 
if there is already a pc on the network at that moment with the same tcp 
address as the one attempting access ?

Any help would be greatly appreciated.

Wayne Hann
wayne@leif.ucs.mun.ca

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Dec 1992 02:32:09 GMT
From:      wayne@kean.ucs.mun.ca
To:        comp.protocols.tcp-ip
Subject:   PCS WITH DUPLICATE TCP ADDRESSES

I am using CMU TCP on a VAX running VMS. I am telneting to this vax from 
PC's using Kermit 3.11 ( which has built-in telnet ).

Many times pc users copy the kermit file from their pc around to other 
machines. One of the files they copy is mskermit.ini that has the tcp 
address of the person's pc. When that file is copied, the receiving machine 
also gets the tcp address of the copying machine. And on it goes. Sometimes 
a whole lab of pc's gets the same tcp address. The network dies a slow 
death.

My question is " Is there a way to prevent a pc from accessing the network 
if there is already a pc on the network at that moment with the same tcp 
address as the one attempting access ?

Any help would be greatly appreciated.

--------------------------------------------------------------------------
Wayne Hann	CA*Net  wayne@leif.ucs.mun.ca
Cabot Institute
St. John's, NF     
--------------------------------------------------------------------------

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Dec 92 18:52:41 EST
From:      cliff@engin.umich.edu (clifford  kaminsky)
To:        comp.protocols.tcp-ip
Subject:   Internet compatibility with WINQVT

Hi. I'm testing out WINQVT/Net version 2.8.  It works fine telnetting to
the university unix machines and such.  Strangely, whenever I telnet to a
MUD (an internet chat system) such as af.itd.com 9999, mustang.dell.com 6715,
wiley.cs.wmich.edu 2345, or svmud.lysator.liu.se 2043, I cannot enter anything.
I receive text normally, but when a prompt comes up, nothing I type gets
sent to the host.

For those of you considering this software for use, it still has a lot of
bugs.

Can someone offer a solution to my problem?  Thanks.

-Cliff

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Dec 1992 13:54:54 GMT
From:      tkevans@fallst (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

wayne@kean.ucs.mun.ca writes:

>I am using CMU TCP on a VAX running VMS. I am telneting to this vax from 
>PC's using Kermit 3.11 ( which has built-in telnet ).
 
>Many times pc users copy the kermit file from their pc around to other 
>machines. One of the files they copy is mskermit.ini that has the tcp 
>address of the person's pc. When that file is copied, the receiving machine 
>also gets the tcp address of the copying machine. And on it goes. Sometimes 
>a whole lab of pc's gets the same tcp address. The network dies a slow 
>death.
 
>My question is " Is there a way to prevent a pc from accessing the network 
>if there is already a pc on the network at that moment with the same tcp 
>address as the one attempting access ?

If kermit supports use of 'bootp' (I don't know if it does), you can
use it to control IP addresses from a central server.  This works on
a real network.  You can get UNIX bootp from CMU.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Dec 1992 14:23:31 GMT
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: ipmulti for SUNOS 4.1.3

Jan.vOorschot@dnpap.et.tudelft.nl (Jan van Oorschot) writes:
> As the title says, i'am looking for ipmulti for SUNOS 4.1.3.
> The standard distribution 
> 
> 	'ipmulti-sunos41x.tar.Z'
> 	
> contains kernel patches for SUNOS 4.1.1 and SUNOS4.1.2, but ...., not
> for SUNOS4.1.3.

The latest version of ipmulti-sunos41x.tar.Z, from gregorio.stanford.edu,
definitely contains patches for 4.1.3 also.

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

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Dec 1992 20:14:35 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

In article <1992Dec19.000209.1@kean.ucs.mun.ca>, wayne@kean.ucs.mun.ca wrote:
>Many times pc users copy the kermit file from their pc around to other 
>machines. One of the files they copy is mskermit.ini that has the tcp 
>address of the person's pc. When that file is copied, the receiving machine 
>also gets the tcp address of the copying machine.

MS-Kermit can use the BOOTP protocol to obtain its IP address from a
server at run-time rather than using an IP address hardwired inside
a local configuration file.  The BOOTP server will hand out an unique
IP address to each machine, usually after using the client machine's
globally unique Ethernet transceiver address as a key to do a table
lookup.

Note that old MSKERMIT.INI files with hardwired IP addresses floating
around on floppies could still cause you problems.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Dec 1992 01:52:16 GMT
From:      jiliu@silver.ucs.indiana.edu (Jian Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet compatibility with WINQVT

Never heard of MUD before.  But have you tried version 3.03 of winqvt?

Jian

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Dec 1992 12:11:07 GMT
From:      wayne@kean.ucs.mun.ca
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

In article <1992Dec19.135454.548@fallst>, tkevans@fallst (Tim Evans) writes:
> wayne@kean.ucs.mun.ca writes:
> 
>>My question is " Is there a way to prevent a pc from accessing the network 
>>if there is already a pc on the network at that moment with the same tcp 
>>address as the one attempting access ?
> 
> If kermit supports use of 'bootp' (I don't know if it does), you can
> use it to control IP addresses from a central server.  This works on
> a real network.  You can get UNIX bootp from CMU.
> -- 
> UUCP:		{rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
> INTERNET:	tkevans%fallst@wb3ffv.ampr.org
> Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

Is there a VMS bootp from CMU ? I looked via FTP and saw unix-based bootp 
files but no VMS-based ones.

/sig

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 92 18:58:09 GMT
From:      guido@gvr.win.tue.nl (Guido van Rooij)
To:        comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Re: Limiting Telnet access.

matt@gecko.oes.orst.edu (Matt Curfman) writes:
#>I have placed a copy of wrapper.tar.Z on anonymous ftp at oes.orst.edu in
#>/pub/386bsd/wrapper.tar.Z.  There are many other sites for this software 
#>as well.
Just ftp it from ftp.win.tue.nl. This is the place where you can always
find the latest version of the tcp-wrapper.
#>-mc
#>_____________________________________________________________________________
#>Matt Curfman                                    Almanac Information Archivist 
#>matt@gecko.oes.orst.edu                     Oregon State University Extension
#
#-Guido

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 1992 13:33:17 -0600
From:      droelke@spirit.aud.alcatel.com (Daniel R. Oelke)
To:        comp.protocols.tcp-ip
Subject:   Problem with Xgopher 1.2 and/or gethostbyname

I just compiled Xgopher 1.2 - my first gopher client.
It appears to work great, but only with numerical IP address.  

The problem I have is that the function call to gethostbyname according
to my man pages only resolves hosts listed in /etc/hosts , but apparently
it is intended to (in net.c of xgopher.c) to access the domain name server
and resolve the host this way.  This defficiency of course creates 
problems as I can't use anything other than the IP addresses for
xgopher.

My big question is: Is there a workaround or fix for this?


The flavor of UNIX I am running is 
"SunOS Release 4.1.2 (GENERIC) #1: "
and I am running OpenWindows 3 (and I have gotten around the problems with
the Xmu library).

Thanks for any and all help you can give me.

Dan Oelke

-----------------------------------_---_--------------------------------------
Dan Oelke                         / \ / \              Alcatel Network Systems
droelke@aud.alcatel.com           \  V  /                       Richardson, TX
Phone: (214) 996-5013              \VMS/             #include <std-disclaim.h>
  Fax: (214) 996-7119               \ / 
-------------------------------------V----------------------------------------


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 1992 05:15:08 GMT
From:      peter@cujo.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: Limiting Telnet access.

In article <1992Dec17.230214.16501@vector.dallas.tx.us>,
tbo@vector.dallas.tx.us (Terry Bohaning) wrote:
> 
> I've recently become very concerned about the security of many of 
> the Unix workstations under my care. Some of the users are overly
> free with their passwords and I would really like to limit access
> to the systems.

Grab log_tcp.  It will log all tcp connections, and deny access to 
certain sets of them (or all except certain sets) on an individual
program basis (as long as the program is started via inetd).  For
example, my setup looks something like this:

ALL : 123.4.567. : NOLOG
in.identd : ALL : LOG
in.ftpd : 123.4.789.80 : NOLOG
gopherd in.ftpd in.telnetd in.rshd in.rlogind in.rexecd : 123.4.789.81
123.4.789.80 : LOG
in.fingerd : ALL : LOG
in.telnetd gopherd in.ftpd : ALL : LOG : /usr/ucb/finger -l @%a |
/usr/ucb/mail -s "Warning, service %d requested by %h [%a]" root &
ALL : ALL : DENY : /usr/ucb/finger -l @%a | /usr/ucb/mail -s "Warning,
service %d requested by %h [%a]" root &

So it allows all services from my logal domain without any logging (which
helps keep the log file size down), logs all identd accesses, no logging of
ftp accesses from a local machine, allows accesses from a few other local
machines (with logging), logs all finger requests, logs all telnet, gopher
and ftp requests and fingers the machine and sends a warning to root (but
of course, all local accesses were previously dealt with, so this only
happens for accesses from strange places), and deny all other access (and
report the possible attack).

BTW, the above includes extensions I made that havent been released to
allow the NOLOG option, but the log_tcp package should do what you want
anyway.

Everyone should be running this, it gives you lots of early warnings, and
totally cuts off a lot of potential attacks.

Have fun all,
   Peter.

_______________________________________________________________________
Peter N Lewis <peter@cujo.curtin.edu.au>             Ph: +61 9 368 2055

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 92 07:15:27 GMT
From:      R.Thirlby@lut.ac.uk
To:        comp.protocols.tcp-ip,comp.windows.ms,comp.windows.x
Subject:   Re: TCP/IP and X under MS Windows 3.1?

We very successfully run Lan work place for Dos with windows 3.1 plus
Hummingbird Exceed x-windows.  we have also used exceed above HP arpa services
for Dos.

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 92 09:04:06 GMT
From:      klaatu@rose.handy.co.kr (Kim)
To:        comp.protocols.tcp-ip
Subject:   How can I get RFC?

Hi,

I want to obtain some RFCs for tcp/ip, SMTP, and so on. I read the book
"Internetworking with TCP/IP" by D. Comer, and found that mailing to
info-server@sh.cs.net could let me to get them, but it does not work now.
Please let me know how I can get RFCs.
Thanks in advance.

-- Kim, Young Hoon
   klaatu@rose.handy.co.kr
   klaatu@sorak.kaist.ac.kr --

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 1992 15:54:16
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RPC ported to DOS environment?

In article <594@fjcp60.GOV> brinkema@fjc.GOV (John R. Brinkema) writes:

    Has anyone ported either TIRPC or Sun RPC 4.0 to the DOS environment?  Is
    there a public domain version?  tnx.  jb.

Sun (PC-NFS Toolkit) and FTP Software (PC/TCP Developer's Kit) were
the first two DOS versions of RPC.  Both appeared prior to RPC 4.0,
and there may be other versions I've forgotten.  We just upgraded to
RPC 4.0 with v2.2 of the Dev Kit, I don't know about Sun.

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


-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 92 23:14:02 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

In article <1992Dec20.094107.1@kean.ucs.mun.ca>, wayne@kean.ucs.mun.ca writes:
> In article <1992Dec19.135454.548@fallst>, tkevans@fallst (Tim Evans) writes:
>> wayne@kean.ucs.mun.ca writes:
>> 
>>>My question is " Is there a way to prevent a pc from accessing the network 
>>>if there is already a pc on the network at that moment with the same tcp 
>>>address as the one attempting access ?
>> 
>> If kermit supports use of 'bootp' (I don't know if it does), you can
>> use it to control IP addresses from a central server.  This works on
>> a real network.  You can get UNIX bootp from CMU.
>> -- 
>> UUCP:		{rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
>> INTERNET:	tkevans%fallst@wb3ffv.ampr.org
>> Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047
> 
> Is there a VMS bootp from CMU ? I looked via FTP and saw unix-based bootp 
> files but no VMS-based ones.
> 
> /sig
--------------
	Yes, MS-DOS Kermit supports both Bootp and RARP. My site prefers
Bootp. However, when we had the main VAX service it with TGV's Multinet
the console log registered each request (translation: monitor screen gets
written all over by such traffic). So we moved the main Bootp server to
a Sun box.
	Just the other day I added a small item which might be useful in
the next release of Kermit. If the Bootp server includes the client's IP
name in the response then I strip off the first word and dot and use the
remainder as the domain extension appended during DNS lookups. It seems 
to be ok so far, and I'll provide an out just in case.
        What I have not done is ping my own IP looking for conficts. I have
a Ping built-in but the trouble of doing this (and explaining results to
users) seems more than it's worth. However, if people feel strongly about it
I can turn on the feature. Last year my students did some simple tests of
bringing up Kermits with the same IP. The worst that happened was a connection
would be dropped as routers got confused. Of course, just plucking IP addresses
out of thin air is plenty of trouble.
        Joe D.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 92 19:09:44 GMT
From:      brinkema@fjc.GOV (John R. Brinkema)
To:        comp.protocols.tcp-ip
Subject:   Sun RPC ported to DOS environment?

Has anyone ported either TIRPC or Sun RPC 4.0 to the DOS environment?  Is
there a public domain version?  tnx.  jb.


-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 1992 19:22:39 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   ProxyArp on Sun

Is there a way to get a Sun that is acting a router between two ethernet
segments (subnets) to proxyarp on one side for devices on the other?

I know how to do this if the routing is between an ethernet and something
else (say a point to point to link). "arp -s REMOTEIP ROUTERETHER public"
will do this. The problem is that this doesn't work with two ethernets
since there is only one arp table for both interfaces.

---
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611



-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 1992 21:03:30 GMT
From:      garnett@refuge.Colorado.EDU (Santiago de la Paz)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: BSD ftpd doesn't work?

In article <BzD6un.2JB@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>karl@ddsw1.MCS.COM (Karl Denninger) writes:
>
>>I'm trying to bring up the ftpd from the wustrl archive; the one UUNET uses.
>>I would like to be able to log connections among other things.
>
>Does it support symbolic links?  My problem is that I can't have
>symbolic links off my anonymous ftp directories.  The directories
>can be made, and will show up when logging into the directory from
>from the shell, or valid login's using ftp, but don't show up when
>logging in via anonymous ftp.

The problem is not the symbolic links, but rather the chroot() that ftpd 
does when you come in as an anonymous user.  Once the ftp homedir is made the
root directory, you can't reach anything outside of it whether symlinked or
not.

~james

-------------------------------------------------------------------------------
  James Garnett, Network Engineer                               (303) 444-1338
  garnett@cogwheel.com

  Cogwheel Incorporated, Boulder  ***  Producers of low-cost dialup IP routers
                        Boulder-Denver/Hong Kong


-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 1992 21:15:08 GMT
From:      tony@mtu.edu (Tony Dal Santo)
To:        comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Re: Limiting Telnet access.

tbo@vector.dallas.tx.us (Terry Bohaning) writes:
>I've recently become very concerned about the security of many of 
>the Unix workstations under my care. Some of the users are overly
>free with their passwords and I would really like to limit access
>to the systems.

Along these lines, I am curious if anyone has an idea how to allow
certain users access to the network, and deny others.  Something
like putting the user in group "network" to grant them access.  By
access, I mean system call level access like socket().  Even better
would be to provide a list of addresses/networks that are restricted/
allowed.

I imagine with a streams implementation of tcp/ip, you could change
the perms on /dev/ip or /dev/tcp.

Does anyone have any utilities for tracing a TCP port to a process number?

Tony Dal Santo
tony@mtu.edu

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 1992 22:12:26 GMT
From:      dean@world.std.com (Dean S Banfield)
To:        comp.protocols.tcp-ip
Subject:   XDR - need implementation

Hi,

We are writing a socket based api set and I want it to support heterogenus
platform use.  Sun seems to have a spec out for eXternal Data Representation
(XDR) so that two dissimilar machines can pass various data types without
regard to hardware implementation.

Our Suns speak happily toeach other, but our SCO box is left out in the cold
because SCO's TCP/IP doesn't supply the XDR calls.  Is there an XDR 
implementation for SCO (public or commercial)?

please e-mail me as I rarely read this group.
thanks in advance.


Dean Banfield
dean@world.std.com
-- 
Dean S. Banfield			Voice: (203) 656-1500
Real Decisions Corporation		FAX  : (203) 656-1659
22 Thorndal Circle			email: dean@world.std.com
Darien, CT 06820

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 1992 22:27:05 GMT
From:      martin@datacomm.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   Using RARP for Greater Security


We are setting up various student labs over our campus which
are connected to Ethernet and ultimately, to the Internet.
We need to use RARP to insure that some fun-loving soul
doesn't start experimenting with changing their IP number and
all the problems that could go along with that.
     We started to use "WinQVTnet," but discovered that there
is a pull-down window which lets the user change his
configuration.  The application we are looking for must run
in "Windows" and not require the running of a DOS window to
support it.  It should support RARP so that the same program
can run on all the PC's and each machine's hardware address
would determine what IP number and host name was assigned.
Any ideas are appreciated.

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

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 92 22:31:02 GMT
From:      geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RPC ported to DOS environment?

Quoth jbvb@ftp.com (in <921221155416@cream.ftp.com>):
#In article <594@fjcp60.GOV> brinkema@fjc.GOV (John R. Brinkema) writes:
#
#    Has anyone ported either TIRPC or Sun RPC 4.0 to the DOS environment?  Is
#    there a public domain version?  tnx.  jb.
#
#Sun (PC-NFS Toolkit) and FTP Software (PC/TCP Developer's Kit) were
#the first two DOS versions of RPC.  Both appeared prior to RPC 4.0,
#and there may be other versions I've forgotten.  We just upgraded to
#RPC 4.0 with v2.2 of the Dev Kit, I don't know about Sun.

Thanks, James. (Why does this feel like passing the mike along the
table at a conference panel session? :-) Our current PC-NFS
Toolkit is 4.0, and it includes TIRPC, XTI and sockets.

Geoff

--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
****************** Please reply to the above address (or geoff@east.sun.com).
* BOGOSITY ALERT * Our netnews software is currently generating bogus sender
****************** addresses. I'll get them to fix it is soon as possible...

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 1992 23:01:49 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: BSD ftpd doesn't work?

In article <BzD6un.2JB@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
>Does it support symbolic links?  My problem is that I can't have
>symbolic links off my anonymous ftp directories.  The directories
>can be made, and will show up when logging into the directory from
>from the shell, or valid login's using ftp, but don't show up when
>logging in via anonymous ftp.

ftpd does a chroot to ~ftp when running "anonymously."  This will make
it very hard for it to find any symbolic links that are absolute paths
relative to / rather than ~ftp.  You will have to come up with some
scheme to have your nfs daemon mount things somewhere in the ~ftp
subtree.  I think this will explain your problem.

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

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Dec 1992 00:40:18 GMT
From:      davek@kestrel.ims.com (Dave Koon)
To:        comp.protocols.tcp-ip
Subject:   Re: Limiting Telnet access.

Someone at MIT modified the inetd daemon to allow service by service allow/deny
capabilities.  This was quite good at allowing a lot of very fine grained 
configuration on any service provided by inetd. I believe that this software
is available via ftp.uu.net.


Dave Koon


-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 1992 02:57:30 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RPC ported to DOS environment?

In article <594@fjcp60.GOV> brinkema@fjc.GOV (John R. Brinkema) writes:
>Has anyone ported either TIRPC or Sun RPC 4.0 to the DOS environment?  Is
>there a public domain version?  tnx.  jb.

'Tis not truly public domain (I think), but it's free: Sun's free XDR and
RPC code, which was ported to MS-DOS as part of the SOSS NFS server for
MS-DOS.  I do not know how well-tested the client side is, but the server
side works well enough to support a working NFS server.

Recent BSD releases include (will include?) NFS, which means they have
to have RPC in there, too.  You could probably port these RPCs to MS-DOS,
if the SOSS port was for some reason unsatisfactory.

Of course, if you want things like documentation and support, you need to
go commercial with FTP SW, Sun, and probably many other MS-DOS TCP vendors.
(I'd be surprised if Beame and Whiteside did not have RPC for MS-DOS.)

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 92 15:34:32 GMT
From:      herbert@lagadia.gnosys.de (Herbert Niederle)
To:        comp.protocols.tcp-ip
Subject:   Re: ProxyArp on Sun

In article 1h55hvINNjdb@emory.mathcs.emory.edu, km@mathcs.emory.edu (Ken Mandelberg) writes:
>Is there a way to get a Sun that is acting a router between two ethernet
>segments (subnets) to proxyarp on one side for devices on the other?
>
>I know how to do this if the routing is between an ethernet and something
>else (say a point to point to link). "arp -s REMOTEIP ROUTERETHER public"
>will do this. The problem is that this doesn't work with two ethernets
>since there is only one arp table for both interfaces.
>
You avoid the problem, if you do the "arp -s" not on the router itself, but
on any other system on each ethernet. The router (Sun) itself has to use its
IP-Routing-Tables.

For example :		----------A----B----C--- Net 1
		R
		----------E----F----G--- Net 2
if you do 

		B# route add <Net 2> B 0
		B# arp -s G R-ether pub

		G# route add <Net 1> G 0
		G# arp -s B R-ether pub
it should work.

Remember, that if R is a Sun you have on both sides the same "R-ether".

Hope that helps,

	Herbert

---
+-------------------------------------------------------+
|Herbert Niederle		Tel: (+49) 89 3083746	|
|GnoSys Software		Fax: (+49) 2156 41485	|
|							|

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Dec 1992 18:32:13 GMT
From:      tony@mtu.edu (Tony Dal Santo)
To:        comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Re: Limiting Telnet access.

tony@mtu.edu (Tony Dal Santo) writes:
>
>Along these lines, I am curious if anyone has an idea how to allow
>certain users access to the network, and deny others.  Something
>like putting the user in group "network" to grant them access.  By
>access, I mean system call level access like socket().  Even better
>would be to provide a list of addresses/networks that are restricted/
>allowed.
>
>I imagine with a streams implementation of tcp/ip, you could change
>the perms on /dev/ip or /dev/tcp.
>
>Does anyone have any utilities for tracing a TCP port to a process number?
>
>Tony Dal Santo
>tony@mtu.edu

Evidently I was not too clear since I have received a few pointers
directing me to inetd wrappers.  I am interested in restricting/granting
users access TO the network FROM my hosts.  I can restrict access to
the binaries (telnet, ftp, etc), but this doesn't stop them from compiling
their own copies of these utilities.  The only way I see to filter access
is to control system calls like socket(), bind(), accept().  I can limit
access to networks via routing tables, but this doesn't provide user-level
granularity.

While inetd wrappers are nice, I don't see them addressing the problem.
Once I get access to your machine, I will bring my own set of utilities
with me (inetd), and avoid the administrators attempts at logging.
Granted that some of the users "daemons" (e.g. ftpd) won't be as functional
as the real ones because they don't run as root, but they will certainly
let me gain access and avoid being logged.  Sure, as an administrator I
can see these processes, and kill them off.  Then the users will restart
them via cron(8) and at(1).  I don't have the time to play hide and seek
with users.

Tony Dal Santo

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 92 18:43:40 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun RPC ported to DOS environment?

>Recent BSD releases include (will include?) NFS, which means they have
>to have RPC in there, too.

The kernel-mode RPC stuff is special hand-coded stuff; the user-mode RPC
stuff is essentially Sun's free RPC 4.0 code.

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Dec 92 19:19:07 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

BOOTP is major bad idea.  You have to configure your routers to pass the
silly stuff 'cuz you won't necessarily have a load host in all subnets.
This means you lose the usual isolation that IP provides you between 
subnets (BOOTP uses a global IP broadcast).

Also, if your BOOTP logs all requests, a station whose download doesn't
get satisfied typically requests every five seconds and ends up filling
up the logs on systems.

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

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 92 20:39:51 GMT
From:      graham@netwrx1.NW1.COM (James M. Graham)
To:        comp.protocols.tcp-ip
Subject:   WINQVT Version 3.0

I have recently downloaded and begun to use the latest (I think) version 
of WINQVT/NET. It says it is the version for Windows 3.1 which is what I
have.

On all systems where it is installed, I have a problem for FTP. I can connect
and login into a host on the network but as soon as I perform a DIR or PUT
or GET a file WINQVT gets hung. It always requires ALT+CTRL+DEL to abort
WINQVT. Sometimes I must reboot the PC to clear things up.

Is anyone experiencing this problem. If so, do you know of a fix?

Do I have the latest version of WINQVT or is there another version. I think
I downloaded it around 3 months ago.

Does anyone know of a way to contact QPC. All I have is the mail address. Can
they be reached via e-mail or telephone?

Has anyone used the NEWS reader interface. I am considering using it to
read news. I have an SCO UNIX 3.2 host with Bnews. Anyone have any hints?

Thanks
Jim


-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 1992 20:43:55 GMT
From:      ekpc@access.digex.com (East Kentucky Power Cooperative)
To:        comp.windows.x,comp.windows.ms,comp.protocols.tcp-ip
Subject:   Re: TCP/IP and X under MS Windows 3.1?


I am using Hummingbird's eXceed/W with Novell's Lan Workplace for DOS.
This works rather well, especially for this site as it is a mixture of
ARCNet and ether.  Except for a for a few cosmetic differences, I have
been rather pleased with the setup.  eXceed/W is up to version 3.2.
(What out for disk 4 in the 3.5" floppy set- all of mine were bad, but 
they were happy to send out a new one)

Fernie


-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Dec 1992 21:15:02 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
>BOOTP is major bad idea.  You have to configure your routers to pass the
>silly stuff 'cuz you won't necessarily have a load host in all subnets.

Yes, like that silly DNS idea where we had to add nameservers just
to support names.  Here we have to add one configuration parameter
to a router for each network.  What a large price to pay for 
automatic configuration of all the machines on that subnet.

>Also, if your BOOTP logs all requests, a station whose download doesn't
>get satisfied typically requests every five seconds and ends up filling
>up the logs on systems.

So your error logs, if turned on, will show a broken system.  That is
a problem because it makes it so much harder to ignore a system 
which is unable to boot up.

Get with the program, and Merry Christmas.

Erick

-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 92 00:31:24 GMT
From:      wjq@uts.amdahl.com (Bill Quigley)
To:        comp.protocols.tcp-ip
Subject:   what to do with those pesky Unix domain socket files

In our new SVR4 kernel, bind() to a unix domain socket creates a file
with the name specified in the bind call.  But if the process is killed,
the file stays around, and when the process comes up again, it cannot
bind to the same name, and gets EADDRINUSE, even though there isn't
a valid socket using that name.

How do others get around this problem?

Thanks.
-- 
Flower Cake - Trends in food come and go, but
the popularity of cookies never wanes - easy to make, easy to eat.
Bill Quigley
Amdahl - UTS CCE
wjq@charon.amdahl.com

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 1992 01:30:13 GMT
From:      taybh@hpsgm2.sgp.hp.com (Beng Hang TAY)
To:        comp.protocols.tcp-ip
Subject:   Comer's book Vol 3 - TLI version?

Hi,
	According to the Comer's book "Internetworking with TCP/IP" Vol 3 BSD
	Socket Version, there is a companion book for TLI version. Does anybody
	know the TLI version is out?

	Thanx.

.Beng-Hang.

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 92 02:52:39 GMT
From:      terry@cs.weber.edu (A Wizard of Earth C)
To:        comp.protocols.tcp-ip,comp.unix.bsd
Subject:   Re: Limiting Telnet access.

In article <1992Dec22.183213.10002@mtu.edu> tony@mtu.edu (Tony Dal Santo) writes:
>tony@mtu.edu (Tony Dal Santo) writes:
>>
>>Along these lines, I am curious if anyone has an idea how to allow
>>certain users access to the network, and deny others.  Something
>>like putting the user in group "network" to grant them access.  By
>>access, I mean system call level access like socket().  Even better
>>would be to provide a list of addresses/networks that are restricted/
>>allowed.
>>
>>I imagine with a streams implementation of tcp/ip, you could change
>>the perms on /dev/ip or /dev/tcp.
>>
>>Does anyone have any utilities for tracing a TCP port to a process number?
>>
>Evidently I was not too clear since I have received a few pointers
>directing me to inetd wrappers.  I am interested in restricting/granting
>users access TO the network FROM my hosts.  I can restrict access to
>the binaries (telnet, ftp, etc), but this doesn't stop them from compiling
>their own copies of these utilities.  The only way I see to filter access
>is to control system calls like socket(), bind(), accept().  I can limit
>access to networks via routing tables, but this doesn't provide user-level
>granularity.
>
>While inetd wrappers are nice, I don't see them addressing the problem.
>Once I get access to your machine, I will bring my own set of utilities
>with me (inetd), and avoid the administrators attempts at logging.
>Granted that some of the users "daemons" (e.g. ftpd) won't be as functional
>as the real ones because they don't run as root, but they will certainly
>let me gain access and avoid being logged.  Sure, as an administrator I
>can see these processes, and kill them off.  Then the users will restart
>them via cron(8) and at(1).  I don't have the time to play hide and seek
>with users.

There is no way to do this short of implementing it in the kernel.  Whether
this is a mod you make to a streams stack or to the Net/2 TCP/IP code is
irrelevant -- as long as it is in the kernel.


As long as users are allowed access to the C compiler/tools, no matter
what you do, they will be able to directly make system calls; therefore
a user space implementation is not useful.

Another implementation doomed to failure is an autopush streams module that
sits between /dev/tcp and the tcp driver.  This is because of the fact that,
even though you may be able to autopush it, the user can I_PEEK and I_POP
it.  An additional difficulty is maintaining the socket assignment state
information for the top layer, since there would not be direct communication
of state information between it and the real TCP stack.

This basically leaves real kernel mods as your only choice, unless you are
willing to go to group limitation and have a streams implementation; even
then, if you allow user mountable devices (floppies, tapes in UFS format,
etc.), the user can make their own device nodes.


Assuming you have a streams implementation, and are willing to go SGID on
all your network utilities, a group "netutil" will work; you can implement
it by removing general permissions to the devices; users will not be able
to implement SGID programs in the "netutil" group without being a member
of the group or superuser.

You might also set group membership for those users allowed unrestricted
access to the devices.


An alternate method is the use of "exclusion groups".  Basically, you set
group ownerships to group "png" of the devices, chmod 606 them.  Since
group access is checked *before* general access, access will be denied
to any member of the group "png".


Finally, you _can_ modify the system calls used for networking (there are
a lot of them) and rebuild your kernel.  This will do little good if you
have streams in any form at all, since it is still possible to build up
utilities from raw I/O to the streams devices or duplicates of the streams
device nodes.

Happy kernel hacking!


------------------
All in all, this generally isn't a reasonable thing to want to do.

An alternate that everyone else uses is to buy a Cisco (or similar box)
and put it between you and the net.  Use the Cisco to limit outgoing
connects to the standard ports

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

Tracing a TCP port (or UDP port, since UDP is usable for TFTP style utilities
in user land) is possible, but requires detailed knowledge of the kernel and
the TCP implementation.  If it is a streams implementation, you'd be better
off providing an instrumentation interface in the streams driver itself to
allow you to do this.  Even then, the information would be unreliable, since
the state of /dev/kmem (where you will be getting at least some of the data)
is not fixed for the duration of your access to it; you will end up with
more of a "snapshot", similar to the "ps" command.

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


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 92 03:51:10 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

In article <1992Dec22.191907.23824@mmm.serc.3m.com>, ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
> BOOTP is major bad idea.  You have to configure your routers to pass the
> silly stuff 'cuz you won't necessarily have a load host in all subnets.
> This means you lose the usual isolation that IP provides you between 
> subnets (BOOTP uses a global IP broadcast).
> 
> Also, if your BOOTP logs all requests, a station whose download doesn't
> get satisfied typically requests every five seconds and ends up filling
> up the logs on systems.


These complaints concern some implementations of bootp clients,
servers, and forwarders, not of the protocol itself.


Vernon Schryver,  vjs@sgi.com

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 1992 04:37:17 GMT
From:      garnett@refuge.Colorado.EDU (Santiago de la Paz)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS SLIP and telnet problem

In article <105528@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
>
>Whenever I try to telnet to a host, it just hangs there...
>What is wrong with telnet?

One of the primary reasons why a telnet attempt like this will hang is if
the remote host cannot reverse-lookup the IP address of the host you're 
coming from.  Make sure that both hosts are forward and reverse-mapped
(just for thoroughness, doncha know) if you're using DNS, or that they're
both in your machine's hosts files.

~james

--------------------------------------------------------------------------------
  James Garnett, Network Engineer                               (303) 444-1338
  garnett@cogwheel.com

  Cogwheel Incorporated, Boulder  ***  Producers of low-cost dialup IP routers
                        Boulder-Denver/Hong Kong


-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 92 12:59:17 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

In article <1992Dec22.191907.23824@mmm.serc.3m.com>, ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
> BOOTP is major bad idea.  You have to configure your routers to pass the
> silly stuff 'cuz you won't necessarily have a load host in all subnets.
> This means you lose the usual isolation that IP provides you between
> subnets (BOOTP uses a global IP broadcast).

Well, the routers we use (Ciscos) can be configured to forward global IP
broadcasts for specific IP protocols to specified sets of "helper" addresses.
This way you can have redundant BOOTP servers without "losing isolation."

Before using BOOTP you should certainly understand how this will affect points
of potential failure for the clients.  For example, is it acceptable for
workstation X to be unbootable or have IP disabled when router Y is down?

> Also, if your BOOTP logs all requests, a station whose download doesn't
> get satisfied typically requests every five seconds and ends up filling
> up the logs on systems.

Whoever wrote the client code should have have spared a few more instructions
in the boot code and made it back off exponentially to some upper limit on the
retry interval.  This isn't a failure of BOOTP, but a poorly designed client...

BOOTP is useful for other things besides loading a boot image.  You can use
it just to provide IP address, netmask, default router, default DNS servers,
and other servers, i.e., all the IP-related things that you have to configure
for individual workstations.

Used correctly, BOOTP can reduce workstation configuration headaches.
--
James Harvey    IUPUI OIT Technical Support/Networks
harvey@iupui.edu  harvey@indiana.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 1992 11:39:59 GMT
From:      isc30236@nusunix1.nus.sg (CHEW CHEE MUN)
To:        comp.protocols.tcp-ip
Subject:   Voice Comm through Ethernet via PC/TCP with SB

I am implementing a voice communication system through Ethernet via
PC/TCP. The sound card I am using for my PC is Sound Blaster Pro card.

The voice output is almost real time.

I am wondering if there is anyone who has done something similar ?
Thank you.

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 1992 12:43:15 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: what to do with those pesky Unix domain socket files

> In our new SVR4 kernel, bind() to a unix domain socket creates a file
> with the name specified in the bind call.  But if the process is killed,
> the file stays around, and when the process comes up again, it cannot
> bind to the same name, and gets EADDRINUSE, even though there isn't
> a valid socket using that name.
>
> How do others get around this problem?

SOP is an unlink() before the bind(), ignoring the return code.

	Rich Stevens  (rstevens@noao.edu)

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 1992 16:15:00 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: PC-NFS SLIP and telnet problem

In article <105528@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
   I'm trying to get SLIP working between a PC using PC-NFS 4.0 and a
   Xylogics Annex 3 terminal server.  I've gotten as far as getting
   NFS to work (mounting a unix directory on the PC over SLIP)

Beware!  Unless you have turned on UDP checksumming on both your NFS
server and your PC, you're in danger of corrupting your files.  SLIP
offers no link-level error detection, and even if you're using modems
with MNP4 or V.42 error correction, things like UART overruns can
introduce errors into the data stream.

SLIP won't notice an error unless the error damages the SLIP frame
flag itself.  IP won't notice an error unless the error damaged the IP
header, which is subject to a checksum.  IP doesn't checksum the rest
of the user data in the packet.  Unless you've turned on UDP
checksumming on both ends of the NFS transaction, UDP won't notice the
error in the user data, and will pass the packet on up the protocol
stack to the NFS software layer.  NFS (at the application layer)
naively assumes it's getting good data from the underlying layers, and
will swallow the bad packet without question.

I have personally experienced file corruption because I used NFS over
a SLIP link.  It can give some very mysterious symptoms...
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 92 16:29:00 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice Comm through Ethernet via PC/TCP with SB

In article <1992Dec23.113959.14553@nuscc.nus.sg> isc30236@nusunix1.nus.sg (CHEW CHEE MUN) writes:
>I am implementing a voice communication system through Ethernet via
>PC/TCP. The sound card I am using for my PC is Sound Blaster Pro card.
>
>The voice output is almost real time.
>
>I am wondering if there is anyone who has done something similar ?
>Thank you.

There's always the "radio" program which runs on (at least) Sun-4s.
While not intended as an interactive tool, it does use UDP/IP.
It uses the built in audio ports to digitize a sound source (typically
a radio output jack) and multicasts the data over an IP net using
UDP datagrams with configured port numbers.  Any Sun wishing to tune
in, listens for multicasts to the desired port number and plays the
sound out that Sun's audio port.

Art

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 92 19:05:09 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

In article <BzoJ13.738@watserv1.uwaterloo.ca>, erick@sunee.uwaterloo.ca (Erick Engelke) writes:
|> > ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
|> >BOOTP is major bad idea.  You have to configure your routers to pass the
|> >silly stuff 'cuz you won't necessarily have a load host in all subnets.
|> 
|> Yes, like that silly DNS idea where we had to add nameservers just
|> to support names.  Here we have to add one configuration parameter
|> to a router for each network.  What a large price to pay for 
|> automatic configuration of all the machines on that subnet.
|> 
|> >Also, if your BOOTP logs all requests, a station whose download doesn't
|> >get satisfied typically requests every five seconds and ends up filling
|> >up the logs on systems.
|> 
|> So your error logs, if turned on, will show a broken system.  That is
|> a problem because it makes it so much harder to ignore a system 
|> which is unable to boot up.
|> 
|> Get with the program, and Merry Christmas.
|> 
|> Erick
|> 
|> -- 
|> ----------------------------------------------------------------------------
|> Erick Engelke				 	            WATTCP Architect
|> erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

Oooooh, such biting sarcasm.

My point is that anyone can set up these systems which will bother
everyone else.  And in a large environment, that is a lot of systems.  I
don't control the desk top so I have to configure the network to avoid
people hurting each other.

Another poster pointed out that you can configure to pass ONLY BOOTP as
far as global IP goes but I still have the problem that I don't control
ANY systems in the network so when these clients are screaming for a
download, it is not in my power to re-configure the workstations who
excessively log the download attempts.

Its bad enough that I will bother the hosts in one subnet but now I will
bother hosts in other subnets.  Typically my customers get real
irritated when hosts from another part of the network bother them.

In any case, in a small environment or a totalitarian one, maybe BOOTP
works but in a large, open environment, it causes about as many problems
as it solves.

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

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1992 19:38:51 GMT
From:      geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS SLIP and telnet problem

Quoth bob@MorningStar.Com (Bob Sutterfield) (in <BOB.92Dec23111456@volitans.MorningStar.Com>):
#In article <105528@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
#   I'm trying to get SLIP working between a PC using PC-NFS 4.0 and a
#   Xylogics Annex 3 terminal server.  I've gotten as far as getting
#   NFS to work (mounting a unix directory on the PC over SLIP)
#
#Beware!  Unless you have turned on UDP checksumming on both your NFS
#server and your PC, you're in danger of corrupting your files.  SLIP
#offers no link-level error detection, and even if you're using modems
#with MNP4 or V.42 error correction, things like UART overruns can
#introduce errors into the data stream.

Agreed. Note that PC-NFS 4.0 ships with UDP checksumming turned on;
you have to explicitly turn it off if you wish to live dangerously.
As Bob says, you still have to check your server, however. On Solaris 2.x
(and, I believe, all SVR4 Unix systems) UDP checksumming is on by default.
On SunOS 4.1.2 it is OFF; to turn it on, patch the value _udp_cksum
in /vmunix to 1 and reboot.

Geoff
--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
****************** Please reply to the above address (or geoff@east.sun.com).
* BOGOSITY ALERT * Our netnews software is currently generating bogus sender
****************** addresses. I'll get them to fix it is soon as possible...

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 92 20:57:17 GMT
From:      smiller@qualcom.qualcomm.com (Scott Miller)
To:        comp.protocols.tcp-ip
Subject:   BootP experience

We have 1000+ PC and Macintoshs connected to our IP network and are
starting to have problems managing these machines.  Due to the fluid
nature of our company, people and equipment are being moved continuously
resulting in incorrectly configured machine being plugged into our net.

One possible solution is to use BootP to assign IP addresses, subnet
masks, default gateways, and domain name servers.  With this information
centralized, users can have their machines reconfigured with a phone call.
Great stuff.

I've downloaded and successfuly been using BootP 2.2 here with two
servers (one on the other side of a cisco configured with BootP directed
broadcasting), three Macintosh's running MacTCP and a PC running FTPPACK.

It seems to work great, but I'd like some feedback from someone using
this in the real world managing 1000+ machines.  Some of my questions
include: How many servers per x nodes/nets?  Has anyone modified bootp
to dynamically assign IP addresses to portable (palm-/lap-tops) machines?
Have any security issues arisen from using BootP?  How much of an impact
does using BootP have on a network in terms of broadcasts/second?  Is
there anything I should be aware of before I start migrating the entire
company to use BootP?

Any input would be greatly appreciated.

Scott Miller <smiller@qualcomm.com>
Supervisor, Network Operations--Qualcomm, Inc.

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 92 22:37:00 GMT
From:      markp@cranham.cc.earlham.edu (Mark Pearson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Help needed with routing Bootp using PCroute


   HEELLLPPPP! I'm having a lot of problems configuring PC Route (the latest  
version - 2.2 I think) to enable BOOTP in a PC Lab. Here is a diagram of the  
current configuration :
     
   159.28.1.1
   ------           SLIP 19.2Kb              ----------       |
   |VAX |------------------------------------|PC Route|-------| PC Lab
   ------  231.254                     231.3 ---------- 30.1  | BOOTP
   BOOTP server
   
   PCs in the Lab send BOOTP requests but time out and fail.  The Vax  
definitely gets the request (if you disable the machine's bootp entry an error  
is registered). I'm not sure whether the problem is:
   a) The Vax may not be sending out replies on the right subnet or
   b) the Router not routing the reply from the Vax

Here is the PC Route log : 
******* PCroute starting *******
Interface 1 (ethernet)
    Address     159.28.30.1
    NetMask   255.255.255.0
    Flags     0000H
    Metric    0001H
    The Ethenet Address 0000H
    The Ethenet Address C01DH
    The Ethenet Address B651H
Interface 2 (slip)
    Address    159.28.231.3
    NetMask   255.255.255.0
    Flags     0000H
    Metric    0001H
    The SLIP baud divisor 0006H
STATIC ROUTES
    Route to network      159.28.1.0
    Through gateway   159.28.231.254
    Metric 0009H
    Flags  0002H
 
Forwarding BOOTP requests to            159.28.1.1
Logging messages to SYSLOGD on host      159.28.1.1
Logging level 0007H
Logging mask 0007H
******* PCroute closing log file *******

From the Lab I can ping 159.28.30.1, 159.28.231.254 but not 159.28.231.3
Why is this?
Similarly from the Vax I can ping the Lab but not the Vax end of the SLIP line  
(159.28.231.254)

This is one of the Multinet files on the Vax (I am standing in for the network  
administartor, hence my ignorance of Multinet):
 
MultiNet IP Routing tables:
Destination     Gateway         Flags        Refcnt Use        Interface
-----------     -------         -----        ------ ---        ---------
LOCALHOST       LOCALHOST       Up,Host      2      19         lo0
159.28.231.1    159.28.231.252  Up,Host      0      74         sl1
159.28.231.2    159.28.231.251  Up,Host      0      678        sl0
159.28.231.3    159.28.231.254  Up,Host      0      368        sl2
159.28.231.4    159.28.231.253  Up,Host      0      0          sl3
159.28.231.251  LOCALHOST       Up,Gateway,H 0      12         lo0
159.28.231.252  LOCALHOST       Up,Gateway,H 0      0          lo0
159.28.231.253  LOCALHOST       Up,Gateway,H 0      0          lo0
159.28.231.254  LOCALHOST       Up,Gateway,H 0      3          lo0
159.28.1.0      159.28.1.1      Up           4      288648     se0
159.28.30.0     159.28.231.3    Up,Gateway   3      2843       sl2
159.28.100.0    159.28.231.2    Up,Gateway   0      130116     sl0
159.28.101.0    159.28.231.2    Up,Gateway   0      0          sl0
159.28.230.0    159.28.1.6      Up,Gateway   0      10737      se0


--
Mark H Pearson	            Coordinator of Academic Computing
Earlham College, Richmond, In 47374
regular e-mail: 	markp@yang.earlham.edu
NeXT mail     : 	markp@cranham.cc.earlham.edu	

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Dec 92 01:28:22 GMT
From:      dyck@mpr.ca (Trevor Dyck)
To:        comp.unix.sys5.r4,comp.unix.questions,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Lachman TCP/IP



Does anyone have the phone number or address for Lachman Associates, Inc.??
They make Lachman TCP/IP which is running on my Unix SVR4.

Actually, any info on Lachman TCP/IP would be appreciated!!

Thanks a lot,

Trevor.
-- 
Trevor Dyck (dyck@mpr.ca)      | "The number of Unix installations has grown 
Advanced Technology Division   |  to 10, with more expected" 
MPR Teltech Ltd. 	       |  -- The Unix Programmer's Manual, 2nd Edition,
8999 Nelson Way, Burnaby, BC   |     June, 1972 

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Dec 1992 12:43:16
From:      edwin@vax.ftp.com  (Edwin Chow)
To:        comp.protocols.tcp-ip
Subject:   Request for Bakeoff Test Proposals

Hi,

On February 8 - February 12 several TCP/IP vendors will be meeting to
test the interoperablity of their products at a "TCP/IP bakeoff".

The following is a form that you can use to submit test cases for the
upcoming TCP/IP bakeoff.  The sponsoring companies will then create these
test cases which will be used to test interoperablity at the bakeoff.

You can also send me your suggestions without using the form and I will edit
them for you.

We feel that it is important to get a wide variety of test proposals from the
internet community in order to understand what are the major concerns 
involving TCP/IP interoperability. While these tests will not be an official
verification suite, we will make the list of tests run at the bakeoff 
available in hopes of helping everyone developing TCP/IP products.

***** Send the tests to me at edwin@wco.ftp.com *****

***** Send further inquires about the bakeoff to bakeoff@TGV.com *****

I will also make the current list of tests available to anyone who is 
interested.

Thanks,

Ed

P.S.  Also enclosed is a press release describing the bakeoff.
---------------------------------------------------------------------------
Edwin Chow - edwin@wco.ftp.com
FTP Software Inc.

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


                        Bakeoff Test Proposal Sheet
                        ---------------------------

Name of Test:
Submitted by:
Phone Number:
Company Name:
Date:

RFC REQUIREMENT LEVEL
(M)ust, (S)hould, m(A)y:

TCP/IP LAYER BEING TESTED
(A)pplication, (T)ransport, (I)nternet, (L)ink:

TCP/IP Feature Being Tested (include RFC reference and page number if
possible:






Brief Description of Test:





Required Length of Test:

Does it requre any other equipment (Yes/No):
If so, what and who will provide it:




TEST SHOULD TAKE PLACE ON THE
(S)table Net, (B)attle Net:

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

Dated:			      December 8, 1992

                         THE  1993  TCP/IP  BAKE-OFF

After much thought and planning, and based on input gleaned from reading an
Internet mailing list of the same name, a group of four companies has come
up with a format for what they hope will the be the first of many multivendor 
"TCP/IP Bake-Off" gatherings.

The first such get-together took place several years ago, when the protocol 
was much younger.  Mr. Jon Postel, one of the original protocol architects, 
worked on a few test meets in December of 1978, January of 1979, and April 
of 1980.  Since then, apart from occasional multivendor networks at shows 
such as UniForum, FCC and INTEROP, there has not been a great deal of 
multivendor testing of the main TCP/IP protocol suite.

While there are groups who meet regularly to work with SNMP, NFS, and similar 
standards, telnet, ftp and smtp - as well as TCP and IP themselves - are mostly
neglected.  This is starting to show up in the fact that there are some 
implementations currently available which are unable to successfully negotiate 
even some of the more basic communications options, or keep network links 
open when hard- or software anomalies occur.

FTP Software, TGV, Empirical Tools and Technology, and InterCon Systems have
taken the example set by Jon Postel and his colleagues, and are building on 
his ideas.  The "TCP/IP Bake-Off" was first announced publicly at the November 
IETF Meeting in Washington DC.  Vendors of products with TCP/IP protocol 
stacks are invited to come, in a spirit of intervendor cooperation, and assist 
in providing network customers with the finest possible range of products 
from which to choose.  As this is a first meeting, the number of participants 
is being limited to between 25 and 30 manufacturers;  and with attendance 
being on a first-come first-served basis, the ranks are filling rapidly.

This will be solely an engineering gathering.  Programmers from many 
competing companies will be there to make sure that their code is able to 
communicate with that of everyone else.  None of the information learned in 
these meetings will go beyond the walls of the meeting venue.  Strict 
guidelines will apply as to what information, and how much of it, is 
disseminated from the Bake-Off;  and to ensure the security of data acquired 
at the Bake-Off, all participants will be governed by a non-disclosure 
agreement.

In the field of networking hardware and software, vendors are confronted with 
a unique paradox:  in order to compete, they have to work together - because 
any networking product that cannot communicate with another networking product 
rather quickly loses its reason to exist....  For this reason, a gathering of 
competitors on neutral ground ends up benefiting the consumer tremendously - 
as well as the vendors themselves who are able to uncover potential problems 
before their customers do, or who were able to return home secure in the 
knowledge that their code is truly solid.

The actual results of this testing and coding will not be made public.  The 
intent is that the participants, by repeatedly coming together, will know 
that their products are good;  and that their customers, knowing that their 
vendor is one of the active participants, will know that the products that 
they are buying are among the most robust available.













-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 24 Dec 1992 15:59:23 EST
From:      <GOVE120@TWNMOE10.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Anyone can tell me more about Telnet usage?

Hi, everyone. I am learning Telnet and have difficulties in operation.
I have the RFC854/855 Telnet protocol specification but it does not help much.
If you have any file or information about how to operate Telnet, please send me
with a e-mail or file. Any information relevant with Telnet will be appreciated
Thank you in advance for your help.

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 1992 13:48:03 GMT
From:      dclunie@pax.tpa.com.au (David Clunie)
To:        comp.protocols.tcpip,comp.sys.sun.hardware,comp.unix.solaris
Subject:   Berkeley Packet Filter for Sun's

I am interested in implementing a filter for controlling the flow
of certain tcpip packets based on source/destination, protocol and
possibly process/user of origin.

I gather from peeking at tcpdump that there is such a thing as the
"Berkeley Packet Filter" mechanism that can be implemented in SunOS 4.1x
if one has a source license which I don't :(

Is there anyone who has done this that could let me have the object
of the appropriately modified modules ?

I am presupposing of course that BPF will be of some use to me, in the
sense that it will allow me to selectively filter packets, rather than
just peek at them !

Thanks ... david


-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Dec 92 17:59:34 GMT
From:      black@ll.mit.edu (Jerry Glomph Black)
To:        comp.protocols.tcp-ip,comp.windows.ms,comp.windows.x
Subject:   Rexec or rsh application for Macs?

Hopefully not too much of a FAQ, but does there exist a simple MacTCP client
which is able to do a simple rexec to a unix host, displaying the result
of the request? I'd like to provide a phone dir lookup and finger utility,
and other functions without forcing users to go into telnet or other big program.

Thanks.
(please copy response to black@LL.MIT.EDU)


-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 92 20:18:22 GMT
From:      jonathan@rahul.net (Jonathan Heiliger)
To:        comp.protocols.tcp-ip
Subject:   Any good TCP/IP books?


    Would anyone reccomend a particular book for learning TCP/IP, and 
networking in general to a greater extent.  I'm planning on taking quite a 
few Data Communications classes, however I would like to have some 
information before I start!
 
-- 
Jonathan Heiliger ........ Electric Power Research Institute
Internet: -/- jonathan@rahul.net -/- jonathan@mecca.epri.com -/-
Telephone <*> (415) 855-2888

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Dec 1992 19:42:02 GMT
From:      stewart@ra.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Any good TCP/IP books?

In article <Bzs5qM.4C1@rahul.net> jonathan@rahul.net (Jonathan Heiliger) writes:
>    Would anyone reccomend a particular book for learning TCP/IP, and 
>networking in general to a greater extent.  I'm planning on taking quite a 
>few Data Communications classes, however I would like to have some 
>information before I start!

Personally, I think that one of the most readable books on the
subject is _Internetworking With TCP/IP: Volume I_ by Douglas
Comer (Prentice-Hall).

/jws

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 1992 03:14:12 GMT
From:      kwia4000@wncs.zrz.TU-Berlin.DE (Manfred Kwiatkowski)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiport repeaters and collision propagation

In article <1992Dec14.193852.28204@alias.com>, chk@alias.com (C. Harald Koch) writes:
|> 
|> What I'm seeing is strange; I can blast data over a TCP/IP connection at
|> over 800Kb/s from host A to host B, but throughput is around 20Kb/s in the
|> reverse direction. Blasting UDP data across the network shows extremely high
|> packet losses in one directory.
|> 
|> There are two multi-port repeaters between the hosts; all cabling is
|> thin-Ethernet. All of my test hosts are the same (SGI Indigos with Allied
|> Telesis Micro-transceivers, all running the same OS revision).
|> 
|> Hosts that are both on the same local thin-net cable (i.e. not talking
|> through a repeater) can talk to each other at high-speed, bi-directionally,
|> without problems. Also, not all repeaters show these symptoms.
|> 
|> I've been monitoring packets on the cables lately to try to figure out
|> what's wrong. If I run monitors on machines 'next to' A and B, I see many
|> packets transmitted by machine B, but that never appear on machine A's
|> cable. The only conclusion I've reached so far is that for some reason, the
|> repeater is dropping packets. (This is supposed to be impossible, due to
|> collision propogation and Ethernet's exponential backoff). Incidentally,
|> netstat on the transmitter shows no output errors and no dropped packets.
 
Two common causes for 'lost packets' on Thinnet-MPRs are:

a) exceeded segment-length limit.
   
   Due to their task, repeaters have to be most 'picky' concerning
   signal levels (receive collision detection scheme) and usually
   operate flakely first in an out-of-specs environment where local
   end-nodes may still communicate. Your observed unsymmetric behavior
   may be due to packet-length dependencies (data >> ACK)

b) grounding problems.

   MPRs with builtin-terminators usually ground the cable. If there
   is a second ground somewhere (e.g another MPR!!) the potential 
   shift may cause peculiar latch-up effects ( watch the collision
   LED) 

Hope this helps...

--
Manfred Kwiatkowski         kwiatkowski@zrz.tu-berlin.de

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 92 11:14:56 MST
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice Comm through Ethernet via PC/TCP with SB

In article <1992Dec23.113959.14553@nuscc.nus.sg>, isc30236@nusunix1.nus.sg (CHEW CHEE MUN) writes:

| 
| I am implementing a voice communication system through Ethernet via
| PC/TCP. The sound card I am using for my PC is Sound Blaster Pro card.
| 
| The voice output is almost real time.
| 
| I am wondering if there is anyone who has done something similar ?
| Thank you.

At Interop '91, TGV, Inc. and Simon Hackett put on a demonstration of voice
over UDP/IP.  They had some bidirectional phones hooked up to PCs, running
voice over the Shownet Ethernet, and also had a unidirectional sound link
receiving an Australian radio station over the Internet and playing it
back (with admittedly less than audiophile-class sound :-)) on a stereo system.

Aaron

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 92 17:39:08 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: PCS WITH DUPLICATE TCP ADDRESSES

In article <1992Dec22.191907.23824@mmm.serc.3m.com> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:

    BOOTP is major bad idea.  You have to configure your routers to pass the
    silly stuff 'cuz you won't necessarily have a load host in all subnets.
    This means you lose the usual isolation that IP provides you between 
    subnets (BOOTP uses a global IP broadcast).

Depends on your perspective.  Setting up IP Routers to forward BOOTP packets
may well be easier than maintaining an RARP server on every LAN cable.  Doing
all IP address configuration on a small set of servers may be easier than
visiting each new system as it's installed (and each time it gets so broken
that you can't log in via Telnet).  The broadcast is only necessary on the
cable which the querying host is attached to - the routers can forward the
requests to the servers as unicasts.
    
    Also, if your BOOTP logs all requests, a station whose download doesn't
    get satisfied typically requests every five seconds and ends up filling
    up the logs on systems.
    
This sounds more like a server software issue than a problem with the
protocol.  I wouldn't turn off logging of failed 'su' attempts, for instance.

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

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Dec 1992 20:43:03 GMT
From:      xsong@marcus.cs.umn.edu (Carol Xiaohui Song)
To:        comp.protocols.tcp-ip
Subject:   Re: How can I get RFC?

In <1992Dec21.090406.7929@kum.kaist.ac.kr> klaatu@rose.handy.co.kr (Kim) writes:

>Hi,
 
>I want to obtain some RFCs for tcp/ip, SMTP, and so on. I read the book
>"Internetworking with TCP/IP" by D. Comer, and found that mailing to
>info-server@sh.cs.net could let me to get them, but it does not work now.
>Please let me know how I can get RFCs.
>Thanks in advance.
 
>-- Kim, Young Hoon
>   klaatu@rose.handy.co.kr
>   klaatu@sorak.kaist.ac.kr --


You can get RFCs through anonymous ftp at site archive.afit.af.mil.
The RFCs are in the directory /pub/rfc/rfc????.Z, where ???? is the
specific RFC doc number.  You can get the numbers from the index file
in the same directory.  Hope you can find what you need. Good luck! 

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

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

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Dec 1992 23:06:04 GMT
From:      jls2@teal.csn.org (Jeff Stoner)
To:        comp.unix.osf.misc,comp.unix.osf.osf1,comp.protocols.tcp-ip
Subject:   DCE Discussions

Are there any newsgroups that we may not be getting, or mailing lists
that I didn't find in the regularly posted lists of such, that deal
with programming in the OSF DCE environment?

I'm very interested in getting together with folks working with DCE,
especially those working on DECs and HPs and Microsoft NT for Intel boxes.

-- 
====== Jeff L. Stoner === Boulder, Colo. ============ /\ = /\ ========== |
                                                 /\  /  \ /  /\  /\    --*--
   Home: jls2 @ bearhug.boulder.co.us         /\/  \/    /  /  \/  /\    |
   News: jls2 @ csn.org                    /\/  \   \  /\  /    \    /\

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 1992 08:40:15 -0500
From:      scoggin@mercury.delmarva.com (John K. Scoggin)
To:        comp.protocols.tcp-ip
Subject:   RMON-Compliant Ethernet Monitors

Does anyone have a list of RMON-compliant ethernet monitors?  I am familiar
with Hewlett-Packard, TTC, and Novell - are there others?

Many thanks.  I will post a summary.

	- John

+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
+---------------------------------------------------------------------+

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Dec 92 08:37:44 GMT
From:      mea@polaris.utu.fi (Matti Aarnio)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: BSD ftpd doesn't work?

Talking about chroot() affecting ftpd's view of the (file)universe..

larry@news.rn.com (Larry Snyder) writes:
>rob@icarus.inmos.co.uk (Robin Pickering) writes:
>
>>   2) Use hard mounts for stuff under ~ftp
>
>How do these large anonymous ftp sites support all these files under
>anonymous ftp?

  For this I can tell you only about one system:  ftp.funet.fi
We have a small directory on the root disk:    /ftp,
in it we have a dozen or so physical mountpoints   (/ftp/disk1 .. disk10),
and to hide them from users, we have extremely hacked  "/bin/ls"  which
has separate control files scattered around our directory tree guiding
its view of the world.  (End result: symbolic links disappear, etc..)

  Back then when that system was started, there was no  lofs  to my
recollection (SunOS 4.0.3), and we haven't used it later for any reason.

  Oh yes,  How do we have a LOT of disks on that host ?  With 3 SCSI host
adapters, and lately  OnLine:DiskSuite metadisks.

>I have files on 4 differenet filesystems, I'm open for ideas on how
>to set them all up under /home/ftp/pub.

  Unless you are able to mount them under ~ftp, consider hard-coded NFF-
mounts (a bit like lofs) or real lofs (SunOS system).
(A friend of mine made such NFS-mounts on their company SysV ISC 2.1 -- ages
 ago..)

>-- 
>Larry Snyder                                    internet: larry@gator.rn.com
>keeper of the Gator                                  uucp: uunet!gator!larry

	/Matti Aarnio <mea@utu.fi> <mea@{nic,ftp}.funet.fi>

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Dec 1992 11:54:08 GMT
From:      peppe@ipgaix.unipg.it (G. Vitillaro)
To:        comp.protocols.time.ntp,comp.unix.aix,comp.protocols.tcp-ip
Subject:   xntp3 socket problem with UDP datagrams from INADDR_ANY.


I had this problem with xntp3 (in xntpd) under AIX/370 1.2.1 (1400).
I'm interested to understand if I met a bug and
if there is any way to go over the problem.

I already posted this problem, but with no answer.
I will be really grateful for any answer that will help me
to understand the nature of this problem, as it may influence
the behaviour of other TCP/IP based packages (the same piece
of code is present in bind 4.8.3 for example).

Here it is the description of the problem:

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

I did some little debugging on xntpd. The problem is that xntpd
seems to hang (no answer to ntqp or xntpdc queries).

Well the xntpd was not really hanging: was just dropping all
the packet coming to him.

The core of the problem seems to be in <ntp_io.c>.

The source define a "wildcard" interface defined that way:

        /*
         * create pseudo-interface with wildcard address
         */
        inter_list[0].sin.sin_family = AF_INET;
        inter_list[0].sin.sin_port = port;
        inter_list[0].sin.sin_addr.s_addr = INADDR_ANY;
        (void) strncpy(inter_list[0].name, "wildcard",
             sizeof(inter_list[0].name));
        inter_list[0].mask.sin_addr.s_addr = htonl(~0);
        inter_list[0].received = 0;
        inter_list[0].sent = 0;
        inter_list[0].notsent = 0;
        inter_list[0].flags = INT_BROADCAST;

This interface (quoted also as any_interface in some subroutine) is
used I think to send packets to a non local network. The problem is
that one time that a just one packet is sent to this interface (that
have address 0.0.0.0) all the packet come from this interface.
But in ntp_io.c (function input_handler) this piece of code:

                                if (i == 0 || free_recvbufs == 0) {
                                        char buf[RX_BUFF_SIZE];

                                        (void) read(fd, buf, sizeof buf);
                                        if (i == 0)
                                                packets_ignored++;
                                        else
                                                packets_dropped++;
                                        continue;
                                }

will drop all the packet coming from the interface 0 [note if (i==0] that
is just the wildcard interface.

If I change the line:
                                if (i == 0 || free_recvbufs == 0) {
to
                                if (free_recvbufs == 0) {

in the above code the xntpd start to work (apparently correctly), although
the <peers> command in xntpdc report 0.0.0.0 for local (I don't know
if this is correct).

Just to finish, if (using the original code) I don't list any peer
the xntpd answer to the local query, I think because no packets was
sent to the interfcae with INADDR_ANY [0.0.0.0] address.

Well (sorry to have bothered the group at this point) my question are:

1) Any idea why all the packet are coming from the wildcard interface?

2) The code I hacked may work without problems?

3) Better ideas in the way to hack this code?

I learned a lot about the use of signals and ASYNC IO (that is supported
by AIX/370 at the end) under UNIX debugging xntpd: my compliment to the
authors, it is a wonderful peace of code.

Best Regards   Peppe

-- 
Giuseppe Vitillaro - IBM SEMEA      |  E-Mail : peppe@ipgaix.unipg.it 
University of Perugia Italy         |  06100 Perugia  Phone:+39.75.585-2200
---------------------------------------------------------------------------
All comments/opinions are mine and don't represent those of IBM

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Dec 1992 14:45:45 GMT
From:      ellis@nova.gmi.edu (Stew Ellis)
To:        comp.protocols.tcpip,comp.sys.sun.hardware,comp.unix.solaris
Subject:   Re: Berkeley Packet Filter for Sun's

dclunie@pax.tpa.com.au (David Clunie) writes:

>I am interested in implementing a filter for controlling the flow
>of certain tcpip packets based on source/destination, protocol and
>possibly process/user of origin.
 
>I gather from peeking at tcpdump that there is such a thing as the
>"Berkeley Packet Filter" mechanism that can be implemented in SunOS 4.1x
>if one has a source license which I don't :(
 
>Is there anyone who has done this that could let me have the object
>of the appropriately modified modules ?
 
>I am presupposing of course that BPF will be of some use to me, in the
>sense that it will allow me to selectively filter packets, rather than
>just peek at them !
 
>Thanks ... david

Check out Weitse Venema's tcp/ip wrappers.  They are archived on many sites,
but the best place to check for them is cert.org.  They work only with tcp
and not with udp.

--
                                                          ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 92 16:36:41 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: what to do with those pesky Unix domain socket files

On 23 Dec 92 00:31:24 GMT, wjq@uts.amdahl.com (Bill Quigley) said:

wjq> In our new SVR4 kernel, bind() to a unix domain socket creates a
wjq> file with the name specified in the bind call.  But if the process
wjq> is killed, the file stays around, and when the process comes up
wjq> again, it cannot bind to the same name, and gets EADDRINUSE, even
wjq> though there isn't a valid socket using that name.

wjq> How do others get around this problem?

There is absolutely no direct way. Some naive and innocent soul will
advise unlinking the socket file before bind, but this of course means
only that you will not get any error notificaton if you start multiple
copies of the daemon.

Simply put, the socket file acts both as a named endpoint and as a lock
that ensure only one daemon serves the socket at one time.

A method which is prone to races is to check for the existence of
another server process before doing the unbind, by trying to open the
socket file and seeing if it is bound to anybody.

A more reliable method is to use a central socket broker; when a daemon
wants to start listening on a socket, it asks the broker by opening a
connection to it; if the broker has no record of a previous request, it
grants it; if it has, it knows whether the server is dead or not (it has
dropped or not the connection to the broker) and then if dead unlinks
the socket file and goes on, if not returns a message to the requestor
saying "already taken".

You could also do an inetd style broker for the Unix domain; then the
broker would know of the death of a server by way of SIGCLD.

If you are thinking of Unix domain sockets for X, then they are usually
associated with a display, and no checking is then necessary, as it is
very rare that the user tries to run two servers on the same display,
and if he does, damn.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 1992 17:09:06 GMT
From:      bansal@cis.ksu.edu (Vivek Bansal)
To:        comp.protocols.tcp-ip
Subject:   Books....


I am looking references to some books which deals with writing system 
software using UNIX and TCP/IP. I already have Comer and Stevens .

I intend to write some device driver using STREAMS, switch software and
other such kind of network software in near future. Any references in this
context would be really appreciated.

Thanks in advance.

Vivek...

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Dec 1992 17:44:29 GMT
From:      oldera@twg.com (Ed Alcoff -  Prod Mtg)
To:        comp.protocols.tcp-ip
Subject:   Re: RMON-Compliant Ethernet Monitors

In article <1hpkfvINN3aj@mercury.delmarva.com> scoggin@mercury.delmarva.com (John K. Scoggin) writes:
>Does anyone have a list of RMON-compliant ethernet monitors?  I am familiar
>with Hewlett-Packard, TTC, and Novell - are there others?
>
>Many thanks.  I will post a summary.
>

Axon Networks in Watertown, MA. has a RMON monitor and applications
to go with it for Sun.  They can be reached at (617) 923-2205.

Metrix has several tools, some of which use RMON, and theirs is
a 'software only' solution versus a standalone hardware box.  They
can be reached at (603) 888-7000.

Happy Holidays,

Ed Alcoff
Product Line Manager
The Wollongong Group, Inc.

#incl std.disc - I am not associated with either company mentioned
and these are my opinions and not those of my employer.

P.S.- I am a Beta test site for Metrix, however.


-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 92 17:49:52 GMT
From:      ajudge@maths.tcd.ie (Alan Judge)
To:        comp.protocols.tcp-ip
Subject:   Re: Any good TCP/IP books?

jonathan@rahul.net (Jonathan Heiliger) writes:
>    Would anyone reccomend a particular book for learning TCP/IP, and 
>networking in general to a greater extent.  I'm planning on taking quite a 
>few Data Communications classes, however I would like to have some 
>information before I start!

For TCP/IP comms in the Unix world, Unix Network Programming by W.
Richard Stevens is the best that I have ever seen.

It is published by Prentice Hall, ISBN 0-13-949876-1
-- 
Alan Judge   ajudge@maths.tcd.ie  a.k.a. amjudge@dsg.cs.tcd.ie +353-1-7021782

"The path of my life is strewn with cowpats from the devils' own herd."
                                          -- Edmund Blackadder II

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Dec 1992 18:06:42 GMT
From:      Jan.vOorschot@dnpap.et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.tcp-ip
Subject:   Re: RMON-Compliant Ethernet Monitors

scoggin@mercury.delmarva.com (John K. Scoggin) writes:

>Does anyone have a list of RMON-compliant ethernet monitors?  I am familiar
>with Hewlett-Packard, TTC, and Novell - are there others?

we have developed a RMON compliant monitor for OS/2, BTNG
(Beholder, the next generation). You can get it
(plus source code) from:
	
	dnpap.et.tudelft.nl:/pub/btng/btng1*.zip
	
It is still in beta.
	
It include the Tricklet SNMP utilities library for both Unix and
OS/2. Somebody has ported Tricklet to DOS.

Documentation is still absent apart from an installation manual.

Jan

-- Ir. Jan van Oorschot.      --- Email: Jan.vOorschot@dnpap.et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
--
-- Ir. Jan van Oorschot.      --- Email: Jan.vOorschot@dnpap.et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 1992 19:03:18 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: BootP experience

Hello, Scott!

You write:
>It seems to work great, but I'd like some feedback from someone using
>this in the real world managing 1000+ machines.

We fit, then.  The last time I checked, we had 3000 machines on our net,
of which about 2500 use BOOTP for configuration.  About 2/3 of those are
MS-DOS, and the rest are Macs.  Probably about a dozen systems use BOOTP
for booting; the rest use it strictly for IP configuration.

>Some of my questions include: How many servers per x nodes/nets?

The standard Unix BOOTP servers use hash tables for their addresses, so
they scale surprigingly well.  We have two main BOOTP servers, for
redundancy, with 4200 lines in the BOOTP table.  (No, I don't know why
there are so many entries for only 3000 hosts.  Either there's some
redundancy in there, someone hasn't been deleting retired network cards,
or my size numbers are out-of-date.)

By the way, we include all known systems in our BOOTP table, not just
those that need BOOTP.  You might want to consider this -- this turned
out to be much more convenient than I expected.

>Has anyone modified bootp to dynamically assign IP addresses to portable
>(palm-/lap-tops) machines?

We treat portables just like normal machines, but we can get away with
that because we are not subnetted.  I don't know how you'd deal with them
on a routed network.

I have heard of dynamic RARP servers.  I do not know whether dynamic
BOOTP servers exist.

>Have any security issues arisen from using BootP?

This has crossed my mind.  Some denial of service attacks are possible
when using BOOTP for config info, but they seem not to be too severe.
I haven't been able to come up with major problems in it when it is used
only for bland config info.

BOOTP-to-boot opens up a whole batch of possible holes, because the boot
kernel is then up for grabs -- anyone who feels like running BOOTP and
TFTP servers can control what kernel the booting machine gets.  That
obviously opens a large can of worms.

Since we use BOOTP pretty much only for config purposes, this latter hole
is not a problem.  The weakness is also common to most diskless-booting
schemes, not just BOOTP.

The thing to remember is that BOOTP should not change your trust decisions,
because there is no way to guarantee that a supposedly BOOTP-configured
machine is what it says it is.

>How much of an impact does using BootP have on a network in terms of
>broadcasts/second?

The impact is utterly miniscule.  I can't get hard numbers for you because
of the date (much of the campus is not here this week), but I can assure
you that we see far more traffic from ARP than from BOOTP.

You can compute some rough numbers yourself.  Assume 1000 computers, all
getting restarted once an hour, 24 hours a day, and assuming that the BOOTP
server always answers their requests on the first try, you should be seeing
one BOOTP broadcast every 3.6 seconds.

These numbers are tuned for worst-case.  Around here, we see one or two
BOOTP broadcasts a minute.

If you are really interested in some hard numbers, drop me a note around
January 20, the beginning of the new semester, and I'll grab a network
analyzer trace to see what kind of numbers we get.  I could also get you
some real numbers on how many machines run BOOTP.

>Is there anything I should be aware of before I start migrating the entire
>company to use BootP?

Not that I can think of.  BOOTP is an incredible boon for large networks.
It saves _immense_ headaches.  We have a base software package that everyone
gets when they get a network card.  (They can add on whatever specialized
packages they need.)  Once the network card driver is installed on the
machine, *no* further customization is necessary.  People can delete their
software and replace it with a copy of their neighbors, and no address
conflicts will result.  It saves a lot of hassle.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 92 20:05:00 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems detecting a dead client connections ??????

In article <1992Dec29.161908.951@nsisrv.gsfc.nasa.gov> sylvain@killians.gsfc.nasa.gov (Gregory Sylvain) writes:
    
    The problem manifests itself when the client end of a tcp client/server 
    connection desides to "go away".  (By "go away", this could mean that the 
    client crashed or that the client actually closed the connection with a 
    successfull call to shutdown(2).)

I'm not a real 4bsd internals expert, but as I understand shutdown(2), it
should send a FIN, initiating a normal TCP connection close handshake.
    
    Given that the connection is non-blocking on both ends.  And provided that
    the server isn't reading or writing from the socket at the time the client
    crashes, THE SERVER WILL NEVER DETECT THAT THE CLIENT ISN'T THERE ANYMORE.

This is true regardless of the blocking/non-blocking state of either end
of the connection, when one end's operating system (or TCP) crashes, or
network connectivity is suddenly lost.
    
    The next time around, when the server tries to read from the socket,
    the server will get an EWOULDBLOCK.  This make some sense, since there 
    obviously isn't any infomation left to read.  But why wont the server 
    get an error more like ECONNRESET or ECONNABORTED.

Ya pays yer penny and gets yer choice...

If you don't mind a steady stream of "keepalive" packets the whole time the
connection is open, then most TCPs will give you an indication when they
haven't gotten any traffic in some time T, whose exact value may be fixed
or configurable depending on the implementation.  On an SGI or other
4bsd-derived TCP, read up on SO_KEEPALIVE.  You might find that it is
easier to design the application protocol with a NOOP command, which can be
used to check connection liveness instead of a TCP keepalive.

But this may well annoy (or bankrupt) users of PayPerPacket networks, or
those with Dial On Demand serial links.  They'll want you to design your
application-layer protocol so that each end has some way of giving up after
waiting "too long", without probing the connection at all.

In short, if you need to know the state of the connection, you need traffic
of one sort or another, which has a cost.

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

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 92 00:23:25 GMT
From:      carrato@mhinfo.UUCP (Tony Carrato)
To:        comp.unix.osf.misc,comp.unix.osf.osf1,comp.protocols.tcp-ip
Subject:   Re: DCE Discussions

In article <Bzzs65.3s@csn.org> jls2@teal.csn.org (Jeff Stoner) writes:
>Are there any newsgroups that we may not be getting, or mailing lists
>that I didn't find in the regularly posted lists of such, that deal
>with programming in the OSF DCE environment?
>
Jeff, there aren't, to the best of my knowledge, any newgroups other than
the two you've found, comp.unix.osf.osf1 and comp.unix.osf.misc.  I'm
seeing relatively little traffic to date in these groups so I suspect
that a DCE newsgroup isn't warranted yet.  (Soon?)  Anyhow, OSF
has got a very active DCE SIG which issues LOTS of email on a regular
basis.  if you're organization belongs to is an OSF member you can probably
get on the distribution.  If not and you have something specific
you want to know, perhaps I can help.  I represent the DEC users' group
to OSF and do get the traffic.

Tony

-- 
----------------------------------------------------------------------------
Tony Carrato				Mile-High Information Services, Inc.
carrato@mhinfo.com			(303) 721-0851
----------------------------------------------------------------------------

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Dec 1992 02:16:27 GMT
From:      mikeg@rocdec.roc.wayne.edu (Michael George)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP vs. PATHWORKS

Recently DEC-NET changed its name to PATHWORKS. This new networking
software promises to do everything including walking the dog. Has anyone
compared TCP/IP with PATHWORKS? Has anyone even tried pathworks. 

I know that TCP/IP will still be around in 5 years, but will PATHWORKS?

Change is a scary thing.

-MG

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Dec 1992 03:52:03 GMT
From:      swslr@well.sf.ca.us (Larry Krone)
To:        comp.protocols.tcp-ip
Subject:   ShareWare TCP/IP Kernels for DOS / Rlogin / FTP ???

Does anybody out there know if / where ShareWare kernels for the above 
systems can be had....Short of shareware, is anything available that
can be licensed at a low cost per seat (under $50)....

Thanx,

Larry Krone
swslr@well.sf.ca.us


-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 92 09:52:48 GMT
From:      rlyle@nl.oracle.com (Rob Lyle  Wizard of Ozje)
To:        comp.protocols.tcp-ip
Subject:   Re: Any good TCP/IP books?

In article <1992Dec25.194202.2135@udel.edu>, stewart@ra.cis.udel.edu (John Stewart) writes:
|> In article <Bzs5qM.4C1@rahul.net> jonathan@rahul.net (Jonathan Heiliger) writes:
|> >    Would anyone reccomend a particular book for learning TCP/IP, and 
|> >networking in general to a greater extent.  I'm planning on taking quite a 
|> >few Data Communications classes, however I would like to have some 
|> >information before I start!
|> 
|> Personally, I think that one of the most readable books on the
|> subject is _Internetworking With TCP/IP: Volume I_ by Douglas
|> Comer (Prentice-Hall).

I second this, with volume two as sunday afternoon play-matgerial 8-)

--Rob.


-- 
Robert P K Lyle		#include <std_disclaimer.h>	**********************
UNIX System Manager					 If I could play the
ORACLE Nederland					Blue Peter theme tune
Rijnzathe 6,	 					   here, I would.
3454 PV  						**********************
De Meern
E-mail:  rlyle@nl.oracle.com				FAX:     +31 3406 65603
Voice:   +31 3406 94211					Private: +31 10 4809140

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 92 10:33:33 GMT
From:      zubin@dworkin.wustl.edu (Zubin Dittia)
To:        comp.protocols.tcp-ip,comp.unix.wizards,comp.unix.internals,comp.unix.misc,comp.unix.programmer
Subject:   Question on kernel memory management.

I am interested in collecting information on the memory management schemes
used for network protocols in MACH (with X-Kernel), System V Unix, and
4.4BSD (I know 4.3BSD used mbufs, but I heard they had been done away
with in 4.4BSD).  If you have any information on these, or know where to
find such information, please let me know.  I'd also appreciate it if
someone could point out a good reference on System V streams for IPC.
My e-mail address is: zubin@dworkin.wustl.edu

Thanks in advance.
                        -Zubin.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 92 14:17:44 GMT
From:      mjr@TIS.COM (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. PATHWORKS

mikeg@rocdec.roc.wayne.edu (Michael George) writes:
>Recently DEC-NET changed its name to PATHWORKS.

	No it didn't. DECnet's still DECnet. Pathworks is a product for
PC desktop access to file and print and login services over a network.
It can use either DECnet or TCP/IP as the transport layer.

mjr.

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 1992 15:41:44 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: ShareWare TCP/IP Kernels for DOS / Rlogin / FTP ???

In article <C0202r.AIA@well.sf.ca.us> swslr@well.sf.ca.us (Larry Krone) writes:
>Does anybody out there know if / where ShareWare kernels for the above 
>systems can be had....Short of shareware, is anything available that
>can be licensed at a low cost per seat (under $50)....

Would you be satisfied with something free or even public domain, or do you
insist on the restrictions, guilt trip, and expense of shareware?  ;-)

There are lots of free software packages for MS-DOS that offer the services
you mention.  CUTCP supports telnet, rlogin, and FTP, among others.  If you
can be happy with telnet instead of rlogin, you can consider WATTCP with
MS-Kermit, NCSA Telnet, ka9q (if you are an educational site or a ham), or
the old Harvard PC/IP suite.  I'm sure there are others I've forgotten.

If you really, really, want shareware, you could try Win/QVTnet.  It runs
under Windows and offers telnet and FTP, among other services.

Followups to comp.protocols.tcp-ip.ibmpc, please.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 92 18:59:01 GMT
From:      apollo@buengc.bu.edu (Doug A. Chan)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS SLIP and telnet problem

In article <1992Dec23.043717.1680@colorado.edu> garnett@refuge.Colorado.EDU (Santiago de la Paz) writes:
>In article <105528@bu.edu> apollo@buengc.bu.edu (Doug A. Chan) writes:
>>Whenever I try to telnet to a host, it just hangs there...
>>What is wrong with telnet?
>One of the primary reasons why a telnet attempt like this will hang is if
>the remote host cannot reverse-lookup the IP address of the host you're 
>coming from.  Make sure that both hosts are forward and reverse-mapped
>(just for thoroughness, doncha know) if you're using DNS, or that they're
>both in your machine's hosts files.

It wasn't any host/IP address problem (FTP, ping, nfsping, NFS, finger all
work fine!)  The host table is okay... just telnet was broken.
I turned on all of PC-NFS' telnet debugging and it got stuck during
the initial negotiation (after it has established a connection with
the host).  Sending a break or 'are you there' from the telnet prompt
sometimes forces the host's login messages to appear but that's about
it... (I still can't type anything to log in)
I bought Advance Telnet (an add-on product to PC-NFS) and it solved the
problem.  I don't know why the standard telnet program that comes with
PC-NFS doesn't work correctly over SLIP (it works fine over ethernet...).

-Doug
apollo@buengc.bu.edu


-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Dec 1992 22:02:58 GMT
From:      amarkel@encore.com (Arieh Markel)
To:        comp.protocols.tcp-ip
Subject:   Help with udp-ip message broadcast

I would appreciate any help, pointers, related RFCs to the area
of protocols of message multicasting.

The problem I am trying to resolve is how to issue a single send
to a (possibly known) set of destination machines that is connected
via IP.

Acknowledgements will (obviously) come at different times from
the different machines that received the message.

Please, respond via e-mail.

Thanks in advance.

Arieh Markel
-- 
 Arieh Markel		  		        Tel: (305)-797-2403
 Encore Computer Corporation                    amarkel@encore.COM
 Optimizer & Instruction Scheduler Group        uunet!gould!amarkel
 Ft. Lauderdale, FL

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 92 08:17:39 GMT
From:      leino@rat.vtt.fi (Tapio Leino)
To:        comp.protocols.tcp-ip
Subject:   Software release problem?



Where should I look for finding the cause of this situation? Could
somebody help us, please.

A simplified of my configuration (there are more segments):


     386 DOS             3COM              IRIX 4.0.5      IRIX 3.3.1
      ______          _____________        __________      __________
      I PC I          I Multiport I        I Pers.  I      I Pers.  I
      I____I          I  repeater I        I  IRIS  I      I  IRIS  I
         I            I___________I        I_4D/25G_I      I_4D/20G_I
         I               I     I               I               I
         I_______________I     I_______________I_______________I
       two thin-Ethernet segments  +  TCP/IP -software (!)


a) If the TCP/IP-software in my PC is the Wollongong WINTCP for DOS
   there is no trouble in connecting the PC (with telnet) to the 4D/20G
   type IRIS with the older IRIX 3.3.1 operating system,
   but it cannot be connected to the other IRIS (with IRIS 4.0.5)?

b) If I am using a product called PCTCP instead of the WINTCP I can
   connect to both IRIS workstations with no trouble.

This started when we took the newest release 4.0.5 of IRIX! Before that I
could connect the PC to both workstations with WINTCP.

We have checked what happens on the lines. The messages seem to go to the
IRIS quite OK but the messages it sends to the PC are not understood by the
WINTCP and everything just stops.

There are two problems which I know of, but could anyone evaluate how much
they have an effect on this situation (they both existed before we took the
IRIX release 4.0.5):

1) the thin-Ethernet segment where the PC in connected is too long (205m)
   but the traffic is quite small!

2) the IRIS with IRIX 4.0.5 has a clear difference in what is its speed
   when inputing data through the Ethernet compared with the output
   speed (which is 10 times faster!). We have asked about the reason for
   it from the Silicon Graphics but they have not found out the reason yet.

Any hints would be greatly appreciated!

-- 
Tapio Leino
Technical Research Centre of Finland / Laboratory of Structural Engineering
mail: VTT/Rakennetekniikan laboratorio, P.O. Box 26, SF-02151 ESPOO, Finland
tel: -358-0-456 6683, telefax: -358-0-456 7003    e-mail: Tapio.Leino@vtt.fi

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 92 14:41:48 GMT
From:      apple@drvax3.msfc.nasa.gov (Kathleen Applegate)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. PATHWORKS

mjr@TIS.COM (Marcus J. Ranum) writes:

>mikeg@rocdec.roc.wayne.edu (Michael George) writes:
>>Recently DEC-NET changed its name to PATHWORKS.
           ^^^^^^^
You're probably thinking of DECnet-DOS, which was a Neanderthal 
predecessor to Pathworks.

>	No it didn't. DECnet's still DECnet. Pathworks is a product for
>PC desktop access to file and print and login services over a network.
>It can use either DECnet or TCP/IP as the transport layer.

Don't forget IPX.  You get the license for that when you buy the
basic Pathworks license ... you just have to buy the media and
documentation kit to actually implement it.  Of course, the IPX
only comes into play with a Novell server--the VMS and Ultrix
servers will expect either DECnet or TCP/IP.  Or at least that's
true until DEC releases its new product for Novell integration
that is an implementation of Novell's portable NetWare.

--
Kathleen Applegate, Sr. Analyst      apple@drvax3.msfc.nasa.gov           
Marshall Space Flight Center             Voice:  (205) 544-7656

END OF DOCUMENT