The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for February 1991 (394 messages, 214863 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/02.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 Feb 91 01:44:39 GMT
From:      ce1zzes@prism.gatech.EDU (Eric Sheppard)
To:        comp.protocols.tcp-ip
Subject:   Problems with NCSA Telnet 2.3b14

I just can't seem to get Telnet to work directly with my ethernet card.
The best I could get was a connection to a remote host.  If I called
telnet without a hostname (which should start server mode), the machine
locks up or reboots.  What am I doing wrong?  I suspect an interrupt
conflict, but the same thing happens with no other cards in the machine.
playing with the specification section of the config.tel file almost
always locks the machine.

Particulars:  80286 machine, 3Com 3c503 Ethernet card.  Also installed
are a memory board, serial/parallel board, 2nd serial card, and bus mouse
board (set to IRQ5).

Pertinent portion of config.tel file:

hardware=3c503
address=dc000
interrupt=3
ioaddr=310
wire=thick

Any pointers appreciated.

Eric

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 01:54:28 GMT
From:      djk@sequent.uucp (Darin Klaas)
To:        comp.protocols.tcp-ip
Subject:   Re: connect "collisions" in TCP

calvert@cs.utexas.edu (Kenneth L. Calvert) writes:


>0.  My impression is that the Berkeley Unix sockets interface (to TCP)
>precludes deliberate use of this "feature".  Have I missed something?
>(The implementation does the right thing when SYN is received in state
>SYN_SENT).

In fact it doesn't do the right thing (at least 4.3-tahoe doesn't) --
follow the incoming SYN ACK and you'll see that the two sides of the connection
eventually SYN ACK each other for ever and ever...

-- darin

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 01:55:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: PC version of tcpdump?

>Does anyone know where I can get a PD version of a PC netwatch or tcpdump
 program available for home use? If so, please respond to me via email, if
>possible.  

To the best of my recollection, netwatch _IS_ PD, or at least free.  Check RFC
1147 for instructions on how to get it (I'd tell you, but my copy of RFC 1147 is
at the office, and I'm not).

Regards,

Bob Stine
bstine@MCIMail.com

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 01:56:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems between Wolligong ftp on VMS and ftp on Sun

>Does anyone know of any problems between Wolligong on VMS and Sun's ftp.
>... If
>I log in just as a user then I get the user name but no prompt for password.
>It just sits there after the carraige return.

Just a wild guess... are you running over ethernet, and if so, are all your
hosts consistent in their "trailer" declarations of the interfaces? (Check
with ifconfig...)

- Bob Stine
  bstine@MCIMail.com

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 11:16:46 GMT
From:      mike@ap542.uucp (Mike Hoffmann)
To:        comp.protocols.tcp-ip
Subject:   SL/IP question

Hi!

We are trying to establish a SL/IP connection between our system
(a Siemens MX-500 with Sinix 5.22) and a DEC MIPS machine running Ultrix 
4.1.

hosta ist our machine
hostb is the DEC MIPS

On our own machine, a SLIP conn is initialized by doing:
  slattach <tty> <baudrate>
  ifconfig sl0 <hosta> <hostb> mtu 256 up

The MIPS machine uses a syntax like:
  slattach <hosta>
and this gets it's information from /etc/sliphosts, where the entry looks
like:
  <hosta> <hostb> <net> ... and so on ...
like it says in the manual.

Funnily though, only hosta can call hostb, but we have found no way
to call our machine from the DEC machine.
Let me add, that there is one other SL/IP connection running on the DEC
machine with no problems whatsoever, bi-directional.

Is only one possible? Is something wrong in the manual entries?
I could understand if it wouldn't work at all, but only in one direction
is ridiculous.

BTW, DEC can't help, their office here states that SL/IP is unsupported.

Thanks for any pointers!
Mike

Mike Hoffmann, Siemens-Nixdorf AG, SNI AP 712  
UUCP: mike@ap542.uucp | INTERNET: mike%ap542@ztivax.siemens.com
"For the new year I resolved, not to be offended by human nature.
But I think I blew it already." (Hobbes)

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 13:26:46 GMT
From:      wilker@gauss.math.purdue.edu (Clarence Wilkerson)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with NCSA Telnet 2.3b14

This may sound silly, but earlier copies of Telenet came with
a batch file TELNET.BAT, which defaulted with blank input to
some local machine address at NCSA. This causes telnet to try that
address, which means a long wait for timeout.
  FTP.BAT on the other hand will just sit quitly after giving
the FTP> prompt. Telnet does seem to have the command line
interface that unix telnet has.
Clarence Wilkerson

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 14:38:05 GMT
From:      cheek@wrdis01.af.mil (Charles Cheek)
To:        comp.protocols.tcp-ip
Subject:   VM TCP-IP communication setup

I have an 8232 with an Ethernet connection attached to 3081.  I have	
two virtual lines defined for TCP-IP.  Why only two lines and can I add more?

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 15:55:57 GMT
From:      dboyes@brazos.rice.edu (David Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: VM TCP-IP communication setup

In article <61@wrdis01.af.mil> cheek@wrdis01.af.mil (Charles Cheek) writes:
>I have an 8232 with an Ethernet connection attached to 3081.  I have	
>two virtual lines defined for TCP-IP.  Why only two lines and can I add more?

Two CTC definitions are all you need; the bandwidth provided by
the CTC connection is much higher than the 8232 can drive anyway.
One is used as the base device for data transfer and the other
CTC is used for control purposes.

Logical terminal devices created by FAL aren't like VTAM or BTAM
in that "ports" or "connections" are not pre-defined and centrally
managed. FAL receives a dynamic connection request from a tn3270
client and creates an LDEV on the fly, no intervention or
configuration on your part necessary.

If you're running SP or HPO, the number of connections is limited
by the 16M VM size; about 400-500 connections. If you're running
in XA mode and have VM/TCP rel 2 (yes, it's available!) and get
the XA-exploitative version from IBM level 1, the number of
connections goes up quite a bit. I haven't received my V2 tapes
yet, so I haven't gotten a chance to mess with it yet.

Now, if you're running MVS TCP, all of the above may be wrong; I
don't have one of those to play with.

-- 
David Boyes       |The three most dangerous things in the world:
dboyes@rice.edu   |  1) a programmer with a soldering iron,
                  |  2) a hardware type with a program patch, and
"Delays, delays!" |  3) a user with an idea.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 16:38:26 GMT
From:      peter@micromuse.co.uk (Peter Galbavy)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.sources.wanted
Subject:   Wanted - PPP for ISC 2.2

I have been trying to hack at the ppp-streams code for SunOS for a
while to get it working under ISC Sys V 3.2 streams for a while - and
I will probably get it going soon. However, it will probably not work,
because I do not understand enough about streams (or ppp for that
matter).

So - has anyone out there got ppp going for Interactive ? If I get the
SunOS version ported before anyone tells me otherwise, I will pass it
back to the world in general, but I do not want to reinvent the whell.

Replies by e-mail please - I will post a summary of there is interest.

Regards,

-- 
Peter Galbavy
Tech Support, Micromuse Ltd
Phone: +44 71 352 7774		E-Mail: P.Galbavy@micromuse.co.uk

Disclaimer: Time flies like an arrow... Fruit flies like a banana

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 17:08:09 GMT
From:      gerke@zeus.unomaha.edu
To:        comp.protocols.tcp-ip
Subject:   PUSH bit in the TCP header question...

I need to know how to force the PUSH bit in the TCP header using the Berkeley
Sockets implementation.  I have seen vague references but no definitive
answer.  I'd be a happy camper if someone could point me in the right
direction...

Thanks!

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 18:35:04 GMT
From:      rpinder@phad.hsc.usc.edu (Rich Pinder)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco,comp.periphs
Subject:   32 bit ethernet adapters

I'm looking for a 32 bit, Micro-Channel, Ethernet adapter, that has
(working) drivers for SCO.

I'd appreciate any leads.  (I know about Cogent - drivers lacking)

thanks

		Rich Pinder
		USC School of Medicine
		(213) 342-1640

		rpinder@usc.edu

    ||||||||||||||||||||||||||||||||||||||||||||||||||

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 19:26:05 GMT
From:      huston@prime.com (Steve Huston)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1108 and IP Security options?

bob@MorningStar.Com (Bob Sutterfield) writes:

>What is the current authoritative reference in this area?  Must an
>implementor order the revised MIL-STD 1777 from Navy Publications (as
>suggested in RFC 1038), or is it available on-line in RFC form?

    RFC 1108 is still being worked on by it's author(s) (not me) and
    is rumored to be available "soon".
    If you plan to operate over military networks, maybe worth ordering
    MIL-STD 1777, else probably better to wait for RFC 1108.

Steve Huston                          huston@relay.prime.com
Prime Computer, Inc.                  +1 508 620 2800 ext 3099

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Feb 91 21:58:32 GMT
From:      pjh@mccc.edu (Pete Holsberg)
To:        comp.protocols.tcp-ip
Subject:   SVR4 and FTP's software

It was suggested to me the other day that the POP servers available in
the P.D. and the POP[23] mail software that FTP supplies with PC-TCP
Plus may not work under the TCP/IP support provided with UNIX System V
Release 4.x.  Could an experienced person please try to shed some light
on this?

Thanks,
Pete
-- 
Prof. Peter J. Holsberg      Mercer County Community College
Voice: 609-586-4800          Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh  1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu	     Trenton Computer Festival -- 4/20-21/91

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 91 23:17:41 GMT
From:      thorinn@diku.dk (Lars Henrik Mathiesen)
To:        comp.protocols.tcp-ip
Subject:   Re: PUSH bit in the TCP header question...

gerke@zeus.unomaha.edu writes:
>I need to know how to force the PUSH bit in the TCP header using the Berkeley
>Sockets implementation.  I have seen vague references but no definitive
>answer.  I'd be a happy camper if someone could point me in the right
>direction...

You cannot explicitly force it. It will be set when the output buffer
drains (i.e., when the sent-but-not-ack'ed mark reaches the end of the
buffer). Depending on the relative speeds of reader, writer and
network, that can be on every packet sent, or never.

However, if your program writes some stuff to the socket and waits for
the other end to acknowledge, the last TCP packet will have been sent
with a PUSH bit. Short of kernel gropery, that is the only way to be
sure.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Feb 91 23:39:19 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection


| From: ericd@sco.COM (Eric Davis)
| 
| Some of the information in this post is incorrect. I do not want to use
| network bandwidth to explain the issues, however I would be more than
| willing to email concerned individuals directly about the the copy
| protection scheme and how it affects system adminstration and users.
| From a techinical and adminstrative point of view SCO's implementation of
| a copy protection scheme it is not the limiting monster that it is
| thought to be. Please take time to understand the facts.

  You didn't help your case in the least with those two incredibly large
and redundant postings.

  First, all the material you quoted had already hit TCP-IP.  You didn't
add any new information in your posting.  If all you wanted to do was to
take the discussion out of a public forum by offering to discuss the
issues privately with individuals, that's all you should have said.
Including the vast amount of already posted material is just going to
piss people off.

  Second you sent the note out twice, but I'll assume that was merely a
mistake on your part.

  As for wanting to take the discussion off of TCP-IP, there have been a
few complaints about the appropriateness of discussing network copy
protection / licensing on TCP-IP from a few people, but since it really
*IS* a network issue, I think that a majority of TCP-IP readers are
probably tolerant of, if not actively interested, the subject.

  I for one would like to see SCO defend its use of network licensing via
broadcast messages.  I have to admit being biased towards disliking it
intensively, but I'd like to hear SCO's arguments.  It may result in some
very productive discussion and decisions.

Casey

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 91 05:33:41 GMT
From:      tcsc@tcsc3b2.tcsc.com (The Computer Solution Co.)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

jgd@Dixie.Com (John G. DeArmond) writes:

>rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik) writes:
 
>>Fellow networkers,
	[ much good stuff deleted ... hope you already saw it ]

>Customer Service will make or break your product.  You'd damn well better
>plan for it as an integral feature of your product, fully as important
>as the software not crashing.  Here's an example of how to and how not to
>do customer support.  I have used 2 brands of intelligent async cards in
>Unix systems for my customers.  One brand is Comtrol and the other is 
>Stargate.  I no longer use Stargate because of customer support.
 
>When I opened the first Comtrol box, the first thing I saw was a plastic gold 
>card just like a credit card.  On this card was printed the 800 toll free 
>support number AND the names and direct dial numbers for the General Manager, 
>the Engineering Manager, the Hardware Tech Support manager, the Software
>Tech Support manager, the Production manager, the Marketing manager and
>the Sales manager.  Above this list of numbers is this statement:
 
>	"Our committment to you doesn't stop with our products.  We give 
>	you the support and the extra service you want.  IT's because your
>	satisfaction is our #1 priority.  COMTROL is only a phone call away.
>	You have full access to all COMTROL personnel.  For your convenience,
>	primary department contacts are listed below:"

	[ more deletions for brevity ]

>Now both boards work pretty well equally.  But I'll never fool with 
>Stargate again while I recommend COMTROL whenever the opportunity arises.
>The difference is service.  I perceived a better value from COMTROL even
>though it cost more.

I have used Comtrol boards for several years now for exactly the same
reason.  When I provide support to my customers, I hope to do as well as
Comtrol.

I hope I'm not allowing the feline to escape the confinement when I say
that I am consulting with Comtrol to develop integrated electronic
delivery of customer support.  Customers will be provided with a BBS,
primarily for DOS and Pick users.  They will also provide uunet and
mailserver access for us networkers.

Fellow networkers ... we should support such companies who really are
trying to do it right at least as strongly as we flame those who botch
it up.

I have no connection with Comtrol, except as a very satisfied customer
for nearly 4 years.  Our consulting engagement for provision of
electronic customer support delivery nets no financial gain to our
company.
_______________________________________________________________________________
David P.  Romig                 INTERNET: tcsc@tcsc3b2.tcsc.com
The Computer Solution Co.         USENET: ...!tcsc3b2!tcsc
P.O. Box 716                     ATTMAIL: attmail!tcsc3b2!tcsc
831 Grove Road                CompuServe: 74116,2345
Midlothian, VA  23113-0716          UUCP: tcsc3b2!tcsc (804)794-1514
Voice: 804-794-3491 x31              Fax: (804)794-6194
_______________________________________________________________________________

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 91 05:55:48 GMT
From:      Dan_Jacobson@ATT.COM
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: Will telnet do VT100 translation for other term types?

>>>>> On 30 Jan 91 16:11:36 GMT, brianop@opac.uucp (BRIAN MCBEE) said:

B> going to buy), but we have people that will be logging in from all
B> kinds of different terminals.  We would then like to be able to
B> telnet from the unix system to a VAX running VMS, and run an
B> application that REQUIRES vt100 terminal emulation.

Perhaps get "screen2" from the comp.sources.unix archive e.g., on
uunet.uu.net.  Only works on BSD/Sun unix though.
-- 
Dan_Jacobson@ATT.COM  Naperville IL USA  +1 708-979-6364

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 91 17:39:36 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

Can copy-protection or license-protection systems such as SCO's be
used for a denial-of-service and/or harassment type of attack?

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105  "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud         "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762 "Chigau. Omae ha gaijin."
  /|\    | |/\| _______  /  \ FAX: (206) 543-3909     "Iie, boku ha nihonjin."
 / | \   | |__|  /   \  /    \MRC@CAC.Washington.EDU  "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 91 19:33:17 GMT
From:      adnan@NCoast.ORG (Adnan Yaqub)
To:        comp.protocols.tcp-ip
Subject:   Customer Support (was Re: copy protection)

In article <6207@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes:
>Customer Service will make or break your product.  You'd damn well better

I agree.

>plan for it as an integral feature of your product, fully as important
>as the software not crashing.  Here's an example of how to and how not to
>do customer support.  I have used 2 brands of intelligent async cards in
>Unix systems for my customers.  One brand is Comtrol and the other is 
>Stargate.  I no longer use Stargate because of customer support.
>
>When I opened the first Comtrol box, the first thing I saw was a plastic gold 
>card just like a credit card.  On this card was printed the 800 toll free 

This sounds like you bought the box from Comtrol.

	[stuff about Comtrol's good support deleted.]

>My Stargate experience was a bit different.  I inherited my first card 
>in some surplus stock I bought.  The card uses address decode PALs that

This sounds like you got Stargate's board at a garage sale.  While I believe
that customer support is important and a company should strive to support
all its products, I don't expect the same support from a company whose
product I inherited with one whose product I bought and is still under
warranty.  Do you?

	[stuff about Stargate's bad customer support deleted]

I suggest that this thread be moved to another newsgroup.  (Which one, I
don't know.)

Adnan Yaqub (adnan@ncoast)

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Feb 91 20:35:30 GMT
From:      jim@remtech.com (Jim Levie)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with NCSA Telnet 2.3b14

ce1zzes@prism.gatech.EDU (Eric Sheppard) writes:

>I just can't seem to get Telnet to work directly with my ethernet card.
>The best I could get was a connection to a remote host.  If I called
>telnet without a hostname (which should start server mode), the machine
>locks up or reboots.  What am I doing wrong?  I suspect an interrupt
>conflict, but the same thing happens with no other cards in the machine.
>playing with the specification section of the config.tel file almost
>always locks the machine.

...stuff deleted...

>Eric

I've recently encountered the same problem and found a solution.
Initially I also thought that it was an interrupt/address clash.
Further investigation revealed that it appears that there is a bug in
the 3c503 routines in telnet and ftp utilities.  Sometimes telnet
would work, sometimes not and sometimes the PC would lock up during or
after a successful connection.  PC's with other ethernet cards didn't
have the problem.

There is a solution... Installing the packet driver for the 3c503 card
appears to have eliminated the problem for us.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 Jim Levie                                  email: jim@chimera.remtech.com
 REMTECH Inc  Huntsville, Al                (or)  ...uunet!remtech!chimera!jim
 The opinions expressed above are just that     Ph.     (205) 536-8581
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 Jim Levie                                  email: jim@chimera.remtech.com
 REMTECH Inc  Huntsville, Al                (or)  ...uunet!remtech!chimera!jim
 The opinions expressed above are just that     Ph.     (205) 536-8581

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 02:09:29 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Advantages/Disadvantages Of TCP+Router Vs. Straight X.25

I would like to get opinions on pros and cons for setting up an
Internet.  The two setups are:

1) All sites on the internet have routers that attach to a public
data network, like UUNET's Alternet, and use TCP/IP to communicate
between nodes on the net.  To the extent that X.25 might be used
underneath TCP between the routers, this is invisible to the
applications.

2) All sites on the internet connect directly to an X.25 network,
and any client-server applications between two sites are written
directly to an X.25 API or to some software abstraction that is
written on top of X.25.

What are the advantages to either approach?  Clearly 2) is going
to be more efficient since you don't have the extra error-checking
of TCP and you don't have the extra data bandwidth of the router
headers being attached to each packet.  This advantage aside, are
there any decisive advantages that argue for approach 1)?

Thanks,
Will Estes        (apple!cup.portal.com!Will)

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 03:23:37 GMT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

> Can copy-protection or license-protection systems such as SCO's be
> used for a denial-of-service and/or harassment type of attack?

    Presumably yes, and very easily. Just run a UDP ECHO server on
port 60000. This might also be a good way of "suppressing" machines
which do these broadcasts from ever getting on your network.

							    Ken

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 03:25:51 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   PC version of tcpdump?

Netwatch is *not* public domain. It's under a copyright that allows
you to do anything you want with it provided that you credit MIT with
its original creation.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 05:41:13 GMT
From:      eps@SUTRO.SFSU.EDU (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

In article <15702@milton.u.washington.edu> MRC@CAC.Washington.EDU
	(Mark Crispin) writes:
>Can copy-protection or license-protection systems such as SCO's be
>used for a denial-of-service and/or harassment type of attack?

Do I detect a missing smiley-face?

					-=EPS=-

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 07:46:56 GMT
From:      whwb@ciba-geigy.ch (Hans W. Barz)
To:        comp.protocols.tcp-ip
Subject:   Re: LM/X and RFC1001

Since we are interested in LM/X I tried to find out, who has really
implemented the RFC1001 correctly. RFC1001 has some nice mechanism build in to
avoid broadcast over internets. The interface on the 'otherwise broadcasting'
client sends a request to the domain server instead. New servers announce
their server capabilities to the domain server as well - this is kind of a new
feature for DNS (interactive update from client).

As a matter of fact no one seems to have implemented it. Only Ungermann/Bass
seems to have plans to do it and they are also delivering an interface to LAN
Manager.

Has somebody more information on that ?

Hans W. Barz, R.1045.3.34, CIBA-GEIGY, 4002 Basel, Switzerland 
   Internet/uucp-Mail: whwb@CIBA-GEIGY.CH
   X.400: C=CH;A=ARCOM;P=CIBA-GEIGY;OU=CHCGBS30;S=BARZ;G=HANS;I=W
   phone: +41/61/6974520
   fax: +41/61/6973288 

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 09:55:00 GMT
From:      ronald@robobar.co.uk (Ronald S H Khoo)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:

> Can copy-protection or license-protection systems such as SCO's be
> used for a denial-of-service and/or harassment type of attack?

Should be.  The serial numbers are broadcast in cleartext.  Just log all
udp broadcasts to port 60000 on any net with SCO stuff on it and see ...
You need to just look at the format of the udp packets, broadcast the
same serial numbers from your own ip address, and that should have the
desired effect of making you extremely unpopular.  Repeat this process
at enough Government sites where SCO have their big moneymaking contracts
and /etc/cpd will disappear from the next release :-)

-- 
Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 12:20:43 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Promiscuous Mode - RS/6000 Ethernet Adapter

I am getting an IBM RS/6000 Real Soon Now, and will be using it for some LAN
monitoring studies.  I need to place the IEEE 802.3 adapter into "promiscuous"
mode, so that it will forward all traffic to my software.

I am aware that this has been done on various Sun and DEC platforms - has
anyone seen any PD code for RS/6000 AIX?

Thanks in advance.

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	scoggin@delmarva.com
Newark, DE  19714	                        
"Never underestimate the bandwidth of a station wagon load of magnetic
 tapes screaming down the interstate!"			

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 13:59:15 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?

I have been trying to interest people in using the Precedence field
where appropriate, as well as TOS.  There are some words in the draft
update of Router Requirements RFC on what the router should do about
precedence (along with what it should do about everything else).
(This document is available as an Internet Draft at the usual places.)
This, too, gets around the problem of the routers having to be told
in advance which protocols are considered important.  It also allows
for the possibility that (for example) some SNMP traffic is considered
very important and other SNMP traffic is considered expendable.

I also drafted a qualitative description of what facilities a host
should have for dealing with the precedence field.  This hasn't been
published anywhere but I'll send it to anyone who asks.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 14:51:35 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: SVR4 and FTP's software

PC/TCP only includes POP[23] clients.  There are at least three
freeware POP3 servers available via the Internet, but I believe they
all assume a Berkeley 'sockets' API for TCP.  If your particular SysV
has a reasonably complete 'sockets' implementation, you shouldn't
have any trouble with the network side of the server, but at least
some SysVs only support AT&T's 'streams' API for TCP.  If you have
one of these, you've got some coding to do...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 16:54:54 GMT
From:      jim@tiamat.fsc.com (Jim O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO TCP/IP copy protection

In article <1991Jan29.232326.4284@anomaly.SBS.COM>, mpd@anomaly.SBS.COM (Michael P. Deignan) writes:
> jacob@gore.com (Jacob Gore) writes:
> 
> >Which is still a pain in the neck for the legitimate user: if you have a
> >hundred machines, you need to keep a hundred sets of floppies for the times
> >when the software on one of the machines needs to restored, and then you
> >need to find the right set of floppies.
> 
> Only one set of floppies, with multiple serialization numbers and 
> activation keys, would be necessary.

Since this is true, I know I would be a whole lot happier with SCO if they
would sell TCP/IP licenses, i.e. a piece of paper with an additional serial
number/activation key combination.  My job as a sysadmin would be much easier
if I could buy one full product, including documentation and media, and then
buy X additional licenses (hopefully, at a somewhat reduced price, since there
is no media or docs involved) to use when installing on machines 2 to X.

The same would be true of the ODT packages (which falls under the same topic
since the TCP/IP is bundled in).  Can you imagine proposing a
site with 100 ODT workstations, and have to figure out what to do with 4400
floppy disks?
------------- 
James B. O'Connor			jim@tiamat.fsc.com
Ahlstrom Filtration, Inc.		615/821-4022 x. 651

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Feb 91 18:11:29 GMT
From:      larry@nstar.rn.com (Larry Snyder)
To:        comp.protocols.tcp-ip,comp.mail.uucp,comp.unix.sysv386
Subject:   uucp over tcpip

I am having problems getting a uucp session going
with another site connected via tcp-ip

what do I need to put as a device in my Systems file?

how do I map the raw device in my Devices file?

-- 
   Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis)
  {larry@nstar.rn.com, ..!uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu}

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 02:14:07 GMT
From:      jsparkes@bwdls49.bnr.ca (Jeff Sparkes)
To:        comp.protocols.tcp-ip
Subject:   SCO <-> Sun == molasses

	I've set up a PC running SCO Unix 3.2.1.  It mostly runs fine, but
FTP and NFS traffic between it and a SparcStation 1+ running SunOS 4.1.1 is
um, pathetic.  FTP transfers of 0.5 K/s.  NFS reads that (almost) never
complete.
	I suspect the window size negotiation breaks down, since telnet
works fine.  Anybody know any workarounds/bugfixes?
--
Jeff Sparkes jsparkes@bnr.ca	Bell-Northern Research, Ottawa (613)765-2503
Another feature is that the seats float, so that the airline can recover
them if the plane crashes into the ocean. -- Dave Barry

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 02:16:03 GMT
From:      mshiels@tmsoft.uucp (Michael A. Shiels)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   SNMP code available?

I have some code which can be run on a PC for gathering SNMP data
from other machines/routers etc.  Is there any code available to
manage/respond to data requests.  Ie the server portion.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 03:06:41 GMT
From:      chris@softway.sw.oz.au (Chris Maltby)
To:        comp.unix.xenix.sco,comp.protocols.tcp-ip
Subject:   SCO Xenix TCP/IP and nameserver problems

We have a Xenix 2.3.2 system with SCO TCP/IP ver 1.0 acting
as a server for our UUCP and other dial-up connections. As we
are running BIND nameservers on other network hosts it seemed
reasonable to enable the named on the Xenix system as a secondary.

We then encountered the following problems.

1) named would cope with several requests ok, say for a few minutes
   then it would fail to respond again. Killing it and restarting
   would repeat the cycle. Sending it the signal which dumps the
   database works fine and the data is ok too. Note that they fail
   to document the requirement for the DOMAIN environment variable to
   be set to your local domain name for named and requesters to even
   work at all!

2) setting up resolv.conf to point at another machine for nameserver
   requests got around problem 1 at the expense of slightly longer delays.
   However, now rlogind (under Xenix) refuses to service requests from
   any of our local machines (and probably elsewhere). Depending on the
   requesting host the error message returned is :

       Address already in use
       EOF on input
       Error 0
    
   which I assume means that rlogind can't cope with domain specified
   addresses being returned by gethostbyaddr() - though it could be
   a problem with the DOMAIN environment variable also.

   The problem goes away if you don't run named or use resolv.conf.

Does anyone have any light to shed on this? We can cope without named
for now, but forthcoming Internet connectivity will strain things a little.

Chris

-- 
Chris Maltby - Softway Pty Ltd	(chris@softway.sw.oz.au)

PHONE:	+61-2-698-2322		UUCP:		uunet!softway.sw.oz.au!chris
FAX:	+61-2-699-9174		INTERNET:	chris@softway.sw.oz.au

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 06:54:51 GMT
From:      FelineGrace@cup.portal.com (Dana B Bourgeois)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

This question is about application licensing.  I am in the process of
planning a 35 node network with PCs running Sun PC-NFS.  One thing I
would really like to do is to  buy 5-10 copies of the popular PC
applications like Microsoft Word and Lotus 123.  I want to put just one
copy on the network server and let users download/execute the application
via PC-NFS.  The problem is with potential licet(n}it(cS~e violations.
Is there a way to enforce the maximum number of simultaneous users?
On Novell Networks there is a product that does this from Rainbow
Software.  But they don't have anything for Unix/TCP/IP networks.{_

Anybody know of a solution so I can satisfy the software license 
restrictions?

Dana Bourgeois @ cup.portal.com
o

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 5 Feb 1991 13:05:14 EST
From:      <EETD2777@Ryerson.Ca>
To:        comp.protocols.tcp-ip
Subject:   Using Kermit on VM_TELNET

I've used Kermit while Telnetted from a VAX to another VAX machine.  It's alot
slower than downloading from the Host machine straight down the my PC but it wo
rks at about half the speed.
I can't use Kermit when telnetting from my VM account to a Vax or a VM it doesn
't work.  Is there any way I can get this to work.
Thanks

Kevin Coutinho
(KISEMAN@YORKVM1, EETD2777@RYERSON)

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 11:36:32 GMT
From:      ucc@ecs.umass.edu
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   UCX and CDCnet problem

We are running UCX v1.3A.  (The "A" if for a patch recommended
by CSC that was applied).  Our hardware is 2 6210s running
VMS 5.4, clustered.

We have an elusive problem, where at times, and not always
on the same node, when a user tries to access the VAXcluster with a
telnet process from a CDCnet device, (TDI) the user
gets the message "USER AUTHERIZATION FAILURE", after typing
in the password.  However the password is correct and not expired,
or preexpired.
Has any body any ideas about this situation?
Thank you!

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 13:13:33 GMT
From:      cliffb@isavax.isa.com (cliff bedore*)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the voltage spec for thinnet?

In article <1991Jan30.155606.21529@dartvax.dartmouth.edu> wbc@moose.dartmouth.edu (Wayne B. Cripps) writes:
>
>
>What should the voltage be on thinnet? - I get readings of
>-1.8 to -2.0 volts and .2 to .3 volts - is this in the
>range?  is 1.2 volts ok?
>
>	Wayne

At the risk of stepping into something soft and gooey, I thought I'd put on
my engineers hat for a while and comment on this.  

First.  It will be very traffic dependent (assuming you're using a voltmeter
that does some averaging).

Having stated that and not knowing the details of an ethernet board, but
knowing something about transmission lines, we can get a wag of ranges for
the voltages.

The lines are 50 ohms and are terminated in 1/4 or 1/2 watt resistors. (Mine
is cause I did it myself and haven't had problems).

Power (watts) = voltage ^2 / resistance or

voltage = sqrt( power * resistance)

voltage = sqrt ( 1/4) * 50 ) or 3.5 volts. for 1/4 watt power

voltage = sqrt ( 1/2 * 50 ) or 5 volts for 1/2 watt power

These are for steady state DC levels.  Ethernet is 10mbit/sec square waves
+- distortion from the coax.  This means the the voltage measures via some
sort of averaging/rms/other meter would be something less (depending upon
the actual waveform, activity on the cable etc.  (This is true for thick or
thinnet. the impedance on the cable is the same)

This the voltages you measure will probably be in the range for correct
operation, but without looking at the waveform, you could have a short with
some DC voltage giving you the same result.

Cliff

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 14:24:31 GMT
From:      huston@prime.com (Steve Huston)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25

Will@cup.portal.com (Will E Estes) writes:

>I would like to get opinions on pros and cons for setting up an
>Internet.  The two setups are:

    You didn't say what sort of sites you're connecting, but from
    your mentioning connecting sites to a PDN, I'm thinking you've
    got clusters of machines, with the clusters connected by X.25
    over PDN...if that's a bad assumption, sorry.

>1) All sites on the internet have routers that attach to a public
>data network, like UUNET's Alternet, and use TCP/IP to communicate
>between nodes on the net.  To the extent that X.25 might be used
>underneath TCP between the routers, this is invisible to the
>applications.
 
>2) All sites on the internet connect directly to an X.25 network,
>and any client-server applications between two sites are written
>directly to an X.25 API or to some software abstraction that is
>written on top of X.25.
 
>What are the advantages to either approach?  Clearly 2) is going
>to be more efficient since you don't have the extra error-checking
>of TCP and you don't have the extra data bandwidth of the router
>headers being attached to each packet.  This advantage aside, are
>there any decisive advantages that argue for approach 1)?

    Approach 1 (TCP) buys you the flexibility of using a standard
    API (sockets, streams, etc.) while retaining the flexibility of 
    changing/adding to your underlying network technology as your network
    grows, changes shape, etc. and communications technology improves.
    You can mix/match non-X.25 network elements with your existing X.25
    parts, and your applications just keep working.

Steve Huston                        +1 508 620 2800 ext 3099
Huston@Relay.Prime.COM              Prime Computer, Inc.

The opinions expressed above are not necessarily those of Prime Computer.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 15:29:19 GMT
From:      robp@gumby.network.com (Rob Peglar)
To:        comp.protocols.tcp-ip,comp.unix.sysv386,comp.unix.xenix.sco
Subject:   Re: Comtrol


I am posting this as a warning to those of you who previously have or
are considering purchasing products from Comtrol Corporation.  This article
is being cross-posted.  The entire article represents the opinion
of the author only and not any other person or organization.  If you don't
know about the multiport serial market and/or Comtrol, just hit "n" now.
 
This is a very sad story.  The year 1990 was a very tumultuous one for
Comtrol.  When I began 1990, taking the position of Manager, Software
R&D, things weren't looking so good.  I had four programmers and two
tech support people working for me, and while their work was quite good,
the overall perception of the company was, as our customers and competitors
put it, "asleep at the wheel".  And so it was;  Comtrol's sales were far
and away based on very old, non-intelligent (aka dumb) product;  although
Comtrol had one (the Smart Hostess line) intelligent product, the
competition had, by far, the lion's share of the intelligent market.
(note, the Ultra 186 was considered part of the Smart Hostess line, and
was in the process of being phased out by the (then unavailable) Ultra 8/16)

At that time, Comtrol was around 35 people.  It was fairly profitable,
since it tended to preserve 60% gross margins as a business priority.  
However, the competition was overwhelming Comtrol in terms of market
share;  while the pie was growing bigger, Comtrol was not growing as
fast as the stockholders would like.  So, the board decided to make
two things happen (at once);  grow the R&D staff, to design and deliver
new products during 1990, and also concentrate on (hopefully) growing
the international market by opening offices in Europe, using local 
(European) personnel.  Comtrol had previously controlled all international
operations from St. Paul.  

(in case you're confused by the terminology, Comtrol is privately held;
the stockholders and the board are one and the same family)

The first strategy, upgrade products/services, worked very well during 1990.
In software, I added three programmers (net), and one tech support person.
Thus, by August, Comtrol had seven programmers and two tech support people.
The hardware R&D group added three engineers and one lab technician.
Customers and competitors had noticed the new products (e.g. Ultra 8/16,
Multivision, etc.etc.) hitting the market; and here's a testimonial from
a real live UseNetter (John DeArmond) about Comtrol service.

--cut--
From ns!noc.MR.NET!msi.umn.edu!umeecs!umich!ox.com!caen!sol.ctr.columbia.edu!emory!rsiatl!jgd Tue Jan 29 12:53:13 CST 1991
Article 7341 of comp.protocols.tcp-ip:
Path: ns!noc.MR.NET!msi.umn.edu!umeecs!umich!ox.com!caen!sol.ctr.columbia.edu!emory!rsiatl!jgd
>From: jgd@Dixie.Com (John G. DeArmond)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: copy protection
Message-ID: <6207@rsiatl.Dixie.Com>
Date: 29 Jan 91 09:04:38 GMT
References: <9101272223.AA08327@desktalk.com>
Organization: Rapid Deployment Systems (making go-fast things and things that-go fast)
Lines: 190

(lots of copy-protection argument stuff deleted)

Customer Service will make or break your product.  You'd damn well better
plan for it as an integral feature of your product, fully as important
as the software not crashing.  Here's an example of how to and how not to
do customer support.  I have used 2 brands of intelligent async cards in
Unix systems for my customers.  One brand is Comtrol and the other is 
Stargate.  I no longer use Stargate because of customer support.

When I opened the first Comtrol box, the first thing I saw was a plastic gold 
card just like a credit card.  On this card was printed the 800 toll free 
support number AND the names and direct dial numbers for the General Manager, 
the Engineering Manager, the Hardware Tech Support manager, the Software
Tech Support manager, the Production manager, the Marketing manager and
the Sales manager.  Above this list of numbers is this statement:

	"Our committment to you doesn't stop with our products.  We give 
	you the support and the extra service you want.  IT's because your
	satisfaction is our #1 priority.  COMTROL is only a phone call away.
	You have full access to all COMTROL personnel.  For your convenience,
	primary department contacts are listed below:"

I've had one occasion to use the support number.  A board arrived one
evening DOA.  I called just at closing time.  COMTROL had someone drive
a board down to Delta DASH and I got it in a few hours.  They told me
to return the DOA one when convenient and not to worry about shipping
back the (very good) documentation.

My Stargate experience was a bit different.  I inherited my first card 
in some surplus stock I bought.  The card uses address decode PALs that
are specific for each OS.  My card was equipped for Xenix and I  needed a
PAL for ISC Unix.  I called up Stargate and reached a rather sullen tech
support technician.  I was told that a new PAL cost $150!!! I passed on
the PAL and obtained one from a friend but ordered a  driver disk for
ISC.  When it got here, it was accompanied by some Nth-generation xeroxed
dot-matrix printed documentation that was practically unreadable and it
would not install.  It did not meet the specifications of ISC's
installpkg facility.  I copied the disk onto the system and installed it
manually. 

Later, I needed to get an upgraded driver for a new version of the OS.  
I called Stargate for the upgrade, somewhat expecting to pay for it.
I was told that I would either have to write (!) to the sales department
who would investigate me as a customer and if I passed, would give me
the secret password to their BBS where I could download the upgrade.
Or I could write and include some money and get a disk.  Write a letter
in order to access a BBS indeed!  Could they have been afraid that I 
had wirewrapped a board in my basement and wanted to steal the driver 
to make it work?  Who knows.

Now both boards work pretty well equally.  But I'll never fool with 
Stargate again while I recommend COMTROL whenever the opportunity arises.
The difference is service.  I perceived a better value from COMTROL even
though it cost more.

(more deletions)

-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it  


--cut--

Well.


As I said, the first strategy was working out.  However - the second was
not, and between it and one heckuva bad decision by the GM of Comtrol
during the spring of 1990 led Comtrol on an ugly downward balance sheet
spiral.  

The Europe strategy was a complete fiasco.  In terms of sales, the sales
numbers were almost dead flat from the international sector, while the
expenses increased by two orders of magnitude.  Despite the board's 
insistent cry that "it's good, don't worry, it will be just peachy in
long run"  the balance sheet was overwhelmed by the cash flowing out of
the company.  The board turned a blind eye toward this, prefering to think
that somehow, a miracle would turn it around.  In fact, things just got
worse.  The GM was replaced in July, but that was too late.  It's hard to
perform major surgery when you cannot stop the flow of blood from the
patient.  As the European office took more and more cash out - in fact,
the office space alone for the eight employees there was larger than the
space for the entire US operation ! - and the marketing expenses went 
through the roof - and the vendors got stretched out to 90, 100, 120, >120
days - and the credit holds started appearing - and the line of bank
credit was maxed out - and on and on.  It was the classic snowball effect.

Are you getting the picture?  Comtrol was going through the classic
small business phenomenon of having increased sales (around 10 percent
overall CY 1990) and going nearly bankrupt at the same time.  The bad
decision in spring 1990 was to order and build up a huge (2 times more
than Comtrol had ever spent in one month) product inventory, hoping that
sales would magically take off in 2H90.  The former GM failed to realize that
the summer is just the wrong time to rely on increased sales, especially
when you've only got three salesmen.  (US)  Well, the cash out was
heavy.  The products built in the spring did not sell (as fast as wanted).
Inventory carrying costs became a burden.  Most US and international 
distributors took a "wait-and-see" attitude, preferring to take normal
quantities of dumb and/or Smart Hostess product.  Cash flew out the door as
marketing bonanzas (like exhibition at Comdex) and $150/night Las Vegas
hotel rooms took their toll.  All the while, R&D costs were held steady as a
percentage of net sales, +- <5 percent.  Even though the company was running
in the red - bigtime - since July, the board continued taking cash out of
the company in the form of "contributions" at the same pace that they always
had.

So, in late November 1990, in a classic, uncreative, knee-jerk, Control
Data-type reaction, the board forced the GM to "eliminate positions" (the
phrase that was used on me), a.k.a. chop heads.  Of course, the R&D groups
were hit hardest; no marketing heads rolled.  Although never stated, the
board clearly took the tactic of eliminating senior (read: decently paid)
people.  Three hardware people were gone.  One SW person (the most senior
in terms of career) was axed; three more (SW) were transferred to different
divisions; the entire production group, whose only flaw was obeying orders,
was dismissed; one (of the two) tech support people was booted.  In all,
around 15 people (out of 55) were chopped.  

Ironically, these changes leave Comtrol almost exactly where it was to start
1990, as we start 1991.  Thus, a whole years' work was discarded.  Sure, the
new products are "there" - but there is hardly anyone left to continue.  In
no way can the current staff maintain the 1990 pace.  Comtrol is certain to
revert back to its "sleepy" posture in the market.  The R&D engine was gutted.
To continue the automobile analogy, the car is now coasting.  1990's rapid
acceleration is now lost; the car will slow down.  It may take a few months,
but it is inevitable.  Comtrol is still in the red, according to internal
sources.  

The board lacks either the foresight, gumption, or ability to raise the 
necessary working capital from either themselves, a public equity or debt
offering, or third-party financing.  Without these sources of working
capital - the banks are now quite wary (side story - the bankers were in
the building on November 26, 1990 "Black Monday".  anytime you see the
bankers in on such a day, it is not a good thing) - Comtrol cannot continue
to provide the level of products and services that Mr. DeArmond came to
know and enjoy.  To use a well-worn cliche, "the party's over" for Comtrol.

From a customer point of view, I would heartily recommend products and
services from either DigiBoard, Equinox, or (esp. internationally) Specialix Ltd.  All have proven themselves to have directors that realize the value of
employees and know how to run a business.  In fact, Digi stock has recently
soared;  they are splitting 2 for 1 (in the form of a dividend);  their
revenues are up 71 % for the most recent FY quarter relative to last years'
same quarter.  There is talk of Digi buying Arnet.  This is not an accident.

People like Gene Olson at Digi, John Pettit at Specialix, and Craig "Wolf"
Kozel at Equinox are fine people.  They won't steer you wrong.  In contrast,
hear a (paraphrased) quote from a current Comtrol employee about the Comtrol
GM:  "every time I talk to (him/her), I feel like I'm getting the big run-
around".  If this happens with employees, what about you, the customer?

Don't get me wrong, now.  The people that are left, for the most part,
at Comtrol are wonderful.  I especially want to tribute the remaining engineering
people - both HW and SW - as their work is top shelf.  There just isn't enough
of them now to maintain what was, what is, and what should be.  The tech
support is one person.  The people that Mr. DeArmond mentioned in his
testimonial - the "gold card" people - are for the most part now gone.
Five out of the seven.  A HW engineer is trying to manage the SW group.  The
entire production load has been transferred to Artist Graphics, where one
can only assume that Comtrol product will get not just second, but Nth banana.
All in all, it is a true shame.

Now, if you are lucky enough to enjoy the tradition of superior Comtrol
service, now and in the future, terrific.  I am quite happy for you.  I
am only saying that the probability of such service is rapidly diminishing.


Moral?  When business turns south - and expenses rise - act immediately.  
	Use your people creatively.  People are not one-dimensional.  
	Engineers can be great salesmen.  If what you need is increased
	sales, make everyone a salesman.  Flexible organizations can
	always survive business downturns - if the board has the fortitude
	and foresight to let change occur.  Chopping 30% of your payroll
	does not solve the problem when the payroll is only 30% of the problem.
	Go after the 70% first - like high inventory, slow sales, super-
	fluous plant, offices, and equipment, unnecessary marketing
	campaigns.  Find the necessary working capital to finance growth,
	People will almost always accept pay cuts rather than layoffs.
	An across-the-board 30% pay cut would have been much more effective
	than a 30% reduction in staff.  The customer ends up suffering.


Absolute truth - don't expand faster than your cash flow allows.  QED.

-- 
Rob Peglar			Network Systems Corporation
Internetwork Group		7600 Boone Avenue North
robp@anubis.network.com		Minneapolis MN 55428	(612)424-4888 x1028

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 15:57:00 GMT
From:      boland@ECF.NCSL.NIST.GOV ("Boland, Tim")
To:        comp.protocols.tcp-ip
Subject:   NIST Ordering Information

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

							November 14, 1990

Below is the information needed to obtain the U.S. GOSIP and NIST/OSI Implemen-
tors Workshop (OIW) documents.  All prices are in U.S. dollars and represent
the most up-to-date information available at this time; for further pricing
information and ordering details, contact the seller (all addresses and tele-
phone numbers are to be found at the end).


                                 +-------+
                                 | GOSIP |
                                 +-------+

GOSIP Version 1.
----------------

GOSIP Version 1 (Federal Information Processing Standard 146) was published in
August 1988.  It became mandatory in applicable federal procurements in August
1990.

Addenda to Version 1 of GOSIP have been published in the Federal Register
and are included in Version 2 of GOSIP.  Users should obtain
Version 2.


GOSIP Version 2.
----------------

GOSIP Version 2 was issued as a draft early in 1989.  It has undergone
public review and comment.  Version 2 was revised to address the comments
received from industry and government; the revisions were subsequently
reviewed and approved by the GOSIP Advanced Requirements Committee in
March, 1990.  Version 2 of GOSIP supersedes Version 1 of GOSIP.  Version 2
of GOSIP makes clear what protocols apply to the GOSIP Version 1 mandate
and what protocols are new for Version 2.

The final text is now available via anonymous ftp.  Version 2
is expected to become a Federal Information Processing Standard (FIPS) in 
early 1991.

    NIST Point of Contact:
	Jerry Mulvenna

    hardcopy:
        NIST Standards Processing Coordinator (ADP)
 
    on-line:
        available through anonymous ftp
        from osi.ncsl.nist.gov (129.6.48.100) as
 
                ./pub/gosip/gosip_v2.txt        -- ascii
                ./pub/gosip/gosip_v2.txt.Z	-- ...compressed
                ./pub/gosip/gosip_v2.ps		-- PostScript
                ./pub/gosip/gosip_v2.ps.Z       -- ...compressed

	available through anonymous ftp from nic.ddn.mil (192.67.67.20) as

                 <PROTOCOLS>GOSIP-V2.TXT        -- ascii
                 <PROTOCOLS>GOSIP-V2.PS         -- PostScript

 
 

             +-------------------------------------------------+
             | NIST Workshop for Implementors of OSI Documents |
             +-------------------------------------------------+

The output of the NIST Workshop for Implementors of OSI (OIW) is a pair of
aligned documents, one representing Stable Implementation Agreements (SIA), the
other containing Working Implementation Agreements (WIA) that have not yet gone
into the stable document.  Material is in either one or the other of these
documents, but not both, and the documents have the same index structure.

The SIA is reproduced in its entirety at the beginning of each calendar year,
with an incremented version number.  Replacement page sets are distributed
subsequently three times during each year (after each Workshop), reflecting
errata to the stable material.  The replacement pages constitute the next
edition of that year's version.

The WIA is reproduced in its entirety after each Workshop (held in March, June,
September and December). OIW attendees automatically receive the WIA.  The final
1990 meeting was on December 10-14; 1991 meeting dates are March 11-15,
June 10-14, September 9-13, and December 9-13, all at NIST.

SIA documentation is available from the U.S. Government Printing Office (GPO),
National Technical Information Service (NTIS), and the IEEE Computer Society.
In the future NIST intends to put SIA documentation
on-line; watch this space for details.

WIA documentation is available from NTIS and the IEEE Computer Society,
as described below.



    NIST Points of Contact for the OIW:

	Tim Boland	--management information
	Chairman, OIW

	Brenda Gray	--administrative information
	OIW Registrar

 

SIA, Version 3.
--------------
This is the appropriate reference for GOSIP Version 1 (FIPS 146) and
GOSIP Version 2 (FIPS 146-1).

SIA, Version 3, Edition 1 (Dec, 1989).
 
The SIA, V3E1 is published as NIST Special Publication 500-177.
It is available from the GPO, NTIS, and the IEEE Computer Society.

Change pages for March 1990 and for June 1990 are available from GPO.
Use the stock number below when ordering these from GPO.
Change pages for March 1990 are available from NTIS.

    hardcopy:

        GPO
        U.S. Government Printing Office
        GPO Stock Number: 903-015-00000-4
        Price: $51.00 (base document + change pages)
               $21.00 (change pages for June and beyond only)
               $63.75 (base document + change pages) (Foreign)

        NTIS (base document)
        Order Number: PB 90-212192
        Price: $60.00 (paper); $17.00 (microfiche)

        NTIS (March 90 Change Pages)
        NIST/SP-500/177-SUP
        Order Number: PB 90-257627/WCC

        IEEE Computer Society Press
        ISBN 0-8186-2075-7
        Catalog No. 2075
        Price: $75.00, $60.00 (Member)
 

WIA (June, 1990).
------------------

The June, 1990 WIA, published as a NIST Interagency Report (NISTIR-4382), is
the most recent copy of the WIA that is available to order.  It is available in
hardcopy from:

	NTIS
	Order Number: NISTIR-4382
                      NTIS Order #: PB 90-259-763
	Price: $45.00 (paper); $11.00 (microfiche)
	       (prices approximate; request pricing information when ordering)


        IEEE Computer Sociey Press
        (Call for Ordering Information)

                           +--------------------+
                           | GOSIP Users' Guide |
                           +--------------------+

GOSIP Users's Guide for GOSIP Version 1
---------------------------------------

This publication assists federal agencies in planning for and procuring
OSI, especially for GOSIP Version 1.  It provides tutorial information on
OSI protocols as well as information on OSI registration, GOSIP technical
evaluation, and GOSIP transition strategies.

    hardcopy:

	NTIS
	Order Number: PB 90-111212
	Price: $23 (paper); $8 (microfiche)


GOSIP Users's Guide for GOSIP Version 2
--------------------------------------- 
 
The companion Users' Guide for GOSIP Version 2 is in preparation.  It should
be available in draft form by February 1991.



                      +-----------------------------+
                      | Addresses/Telephone Numbers |
                      +-----------------------------+

	Jerry Mulvenna
	Technology, B217
	Gaithersburg, MD  20899
	(301) 975-3631
	mulvenna@ecf.ncsl.nist.gov

	Tim Boland	--management information
	Chairman, OIW
	Technology, B217
	Gaithersburg, MD  20899
	(301) 975-3608
	boland@ecf.ncsl.nist.gov

	Brenda Gray	--administrative information
	OIW Registrar
	Technology, B217
	Gaithersburg, MD  20899
	(301) 975-3664

	National Technical Information Service (NTIS)
	U.S. Department of Commerce
	5285 Port Royal Road
	Springfield, VA  22161
	(703)487-4650

	IEEE Computer Society Press
	Order Department
	10662 Los Vaqueros Circle
	Los Alamitos, CA  90720
	1-800-272-6657

	U.S. Government Printing Office 
	Washington, DC  20402 
	(202) 783-3238

	Standards Processing Coordinator (ADP)
	National Institute of Standards and Technology
	Technology Building, Room B-64
	Gaithersburg, MD  20899
	(301) 975-2816

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 18:51:53 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: SVR4 and FTP's software

>If your particular SysV has a reasonably complete 'sockets'
>implementation, you shouldn't have any trouble with the network
>side of the server, but at least some SysVs only support AT&T's
>'streams' API for TCP.  If you have one of these, you've got some
>coding to do...

Or, if it's S5R4 and it's one of those, you've got some
yelling-at-the-vendor to do, 'cuz S5R4 systems are *supposed* to come
with a reasonably complete sockets implementation....

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Feb 91 20:50:01 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix.sco,comp.unix.xenix.misc,comp.unix.sysv386,comp.unix.sysv286
Subject:   3c501 users please read this

Sorry to post this so widely, but since the question has come up
recently twice on the net, and twice locally to Clarkson, people
should be aware of this problem.

The 3c501 cannot receive back-to-back packets (two packets addressed
to the same host with no intervening packet).  BSD Unix (well, SunOS
and NeXTos at least) will attempt to fill your TCP window by sending
back-to-back packets.  Therefore, your TCP Window must not be larger
than your TCP MSS.

  o Under KA9Q, use "tcp window 1024" and "tcp mss 1024".
  o Under SCO Xenix, use the UNDOCUMENTED ifconfig option -onepacket.
  o Under NCSA Telnet, use "maxseg=1024" and "rwin=1024".
  o Under FTP Software's PC/TCP, use "ipconfig window 1024".

--
--russ <nelson@clutx.clarkson.edu> Humble Quaker, and damned proud of it.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 01:45:05 GMT
From:      oldera@MERCURY.TWG.COM
To:        comp.protocols.tcp-ip
Subject:   Software Partners 32

Greetings,

		I am looking for a contact, marketing-type preferably, at the
above company.  At the least, a telephone number would be nice.

		Thanks in advance,

Regards,

Ed Alcoff
Product Manager
The Wollongong Group, Inc.
1129 San Antonio Rd.
Palo Alto, Ca.  94303

e-mail: oldera@twg.com
voice:   (415) 962-7240
fax:      (415) 962-5547

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 03:34:24 GMT
From:      jb@falstaff.mae.cwru.edu (Jim Berilla)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the voltage spec for thinnet?

In article <1991Feb5.131333.2047@isavax.isa.com> cliffb@isavax.isa.com (cliff bedore*) writes:
>In article <1991Jan30.155606.21529@dartvax.dartmouth.edu> wbc@moose.dartmouth.edu (Wayne B. Cripps) writes:
>>
>>
>>What should the voltage be on thinnet? - I get readings of
>>-1.8 to -2.0 volts and .2 to .3 volts - is this in the
>>range?  is 1.2 volts ok?
>>
>>	Wayne
>
>At the risk of stepping into something soft and gooey, I thought I'd put on
>my engineers hat for a while and comment on this.  
>
>First.  It will be very traffic dependent (assuming you're using a voltmeter
>that does some averaging).

True.  Don't use a voltmeter, use an oscilloscope.  You'll see many interesting
things.

>Having stated that and not knowing the details of an ethernet board, but
>knowing something about transmission lines, we can get a wag of ranges for
>the voltages.

Not true.  The voltages on the ethernet are clearly defined.

>The lines are 50 ohms and are terminated in 1/4 or 1/2 watt resistors. (Mine
>is cause I did it myself and haven't had problems).
>
>Power (watts) = voltage ^2 / resistance or
>
>voltage = sqrt( power * resistance)
>
>voltage = sqrt ( 1/4) * 50 ) or 3.5 volts. for 1/4 watt power
>
>voltage = sqrt ( 1/2 * 50 ) or 5 volts for 1/2 watt power

What *are* you talking about?  (And take off that silly hat.)
In the case of ethernet, the voltage depends on the amount of current
pulled out of the tap.  It's independant of the power rating of the
terminating resistors.  Remember that the tap appears as a 25 ohm load,
i.e. it's connected to two 50 ohm transmission lines.

For the AM7996 transceiver (common in a lot of Sun's), the voltages are
specified as follows:  High level is between 0 and -.1 volts, low level
is between -1.625 and -2.2 volts.  As stated above, this voltage is
generated by a current sink (to -9V) by the chip.  An ideal current sink
has infinite impedance, and doesn't load the transmission line.  If two
or more stations transmit at the same time, the voltage on the line goes
below -2.2 volts.  The chip detects collisions on this basis.

>These are for steady state DC levels.  Ethernet is 10mbit/sec square waves
>+- distortion from the coax.  This means the the voltage measures via some
>sort of averaging/rms/other meter would be something less (depending upon
>the actual waveform, activity on the cable etc.  (This is true for thick or
>thinnet. the impedance on the cable is the same)
>
>This the voltages you measure will probably be in the range for correct
>operation, but without looking at the waveform, you could have a short with
>some DC voltage giving you the same result.

You can use a meter for a few tests on the ethernet, but it's very limited.
On an inactive network, an ohmmeter accross the tap will read 25 ohms.  If
there are any stations transmitting, the reading will be jittery.  If the
network is shorted, it will read close to zero ohms.  If a terminator is
bad, or there is a break in the line, it will read 50 ohms.  A voltmeter
might tell you something, but I wouldn't use it if there's a scope around.


-- 
      Jim Berilla / jb@falstaff.cwru.edu / 216-368-6776
"My opinions are my own, except on Wednesday mornings at 9 AM,
           when my opinions are those of my boss."

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 08:16:24 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: UCX and CDCnet problem

ucc@ecs.umass.edu writes:

>We are running UCX v1.3A.  (The "A" if for a patch recommended
>by CSC that was applied).  Our hardware is 2 6210s running
>VMS 5.4, clustered.
 
>We have an elusive problem, where at times, and not always
>on the same node, when a user tries to access the VAXcluster with a
>telnet process from a CDCnet device, (TDI) the user
>gets the message "USER AUTHERIZATION FAILURE", after typing
>in the password.  However the password is correct and not expired,
>or preexpired.
>Has any body any ideas about this situation?
I have no idea on the "USER AUTHORIZATIOn FAILURE", but we also
have trouble with CDCnet -> UCX1.3A

Our problem:
If somebody trys to connect from a CDCnet node to our VAX, the connection
sets up, but he get no prompt, until he/she types in a Break-character.
With some debugging, we found out, that the VAX doesn't respond immediately
with a login prompt, if the other side doesn't support the Terminal Type option
(as in CDCnet!). The prompt appears after some input, like a local
terminal. That dolt CDCnet isn't able to send a character at this stage,
only BREAK got it to send something! So there are two problems,
one side is UCX which barfs on a missing Terminal Type Option, 
and CDCnet which isn't able to send at this stage.

Sincerely,
Klaus Steinberger
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
BITNET: K2@DGABLG5P             Internet: k2@bl.physik.tu-muenchen.de

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 13:51:37 GMT
From:      martino@logitek.co.uk (Martin O'Nions)
To:        comp.protocols.tcp-ip
Subject:   Re: LM/X

WARD@CC.UMontreal.CA writes:

>BTW, anyone one the net is running LAN Manager/packet driver combination ?
>We would like to do so (and then use NCSA Telnet with LAN Manager).
>We are also interested in adding a mail service in this configuration.
>Any experience someone ?

We don't use the packet drivers regularly with LM, largely because we have
the 3+ Open TCP software kicking around everywhere, but we did run PC/TCP
with LM for test purposes. There is a Packet Driver to NDIS TSR which feeds
the packet driver requests into the NDIS stack, and feeds the response
back up the chain. We had problems with early versions of this when doing
repeated loads/unloads of the driver, (it crashed the machine) but I believe
that this has been addressed (comments anybody?)

Martin

--
DISCLAIMER: All My Own Work (Unless stated otherwise)
--------------------------------------------------------------------------
Martin O'Nions            Logitek Group Support      martino@logitek.co.uk
--------------------------------------------------------------------------
      Auntie did you feel no pain / Falling from that willow tree?
     Could you do it, please again / 'Cos my friend here didn't see.
         (Harry Graham - Ruthless Rhymes for Heartless Homes)

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Feb 91 14:02:07 GMT
From:      Zhen Li <lizhen@silver.ucs.indiana.edu>
To:        comp.protocols.tcp-ip
Subject:   summary on transferring motion picture over IP

Since I posted inquiry about transferring video over IP I 
have received  more requests for  summary than answers to 
the question.  Following is  what I have got so far.  

Many thanks to those who provided helpful information.  I 
appreciate all of your help.  Thanks!

Jane

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

From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston)

I've seen experimental products that can handle about 1
4x5 inch 8-bit color image every 2 seconds.  The problem is
not the TCP/IP protocols per se, but the fact that they
"typically" run over network media that are one or two orders
of magnitude too slow for animated/video images.

Count up the number of pixels in one frame, multiply by the
number of bits behind each pixel, then compare to the 10 Mbits/sec
serial bit rate of Ethernet.  I think you'll find a major
mismatch.

--------------------------------------------------------------------------
Claudio Topolcic <topolcic@bbn.com>


        I don't have exactly the answer for you, but we routinely send
live video across a DARPA-sponsored network in support of video conferencing.
The network is called the Terrestrial Wideband Network, and we have multi-protoc
ol
routers that implement the ST protocol (formerly IEN 119, and now RFC 1190) as
well as IP. This is a connection oriented internet protocol intended to support
real-time applications such as voice and video. We use commercial video codecs
to compress the video down to about 128 Kbps

--------------------------------------------------------------------------
From: I.Wakeman@cs.ucl.ac.uk


in reply to your request about video over IP, a fair amount of work is currently
going on in this area, between UCL, BBN and others, using the ST protocol in
the ARPA Wideband Terrestial Network (SIGCOMM90 paper). Currently ST is running
separately from IP traffic, but real soon now, ST will be running over IP in
the BBN gateways, and in BSD socket code that Craig Partridge is writing. Other
work of interest is at UCB on DIstributed Continuous Media, David Anderson.
There's also been an RFC on time critical constraints on data networks -
something like 91 in the current series.The BSD people are interested in producing 
a UDP variant that can carry time critical data using time stamps.

...
anyway, two rfcs of interest are:
1193: client requirements for real-time communications services
1192 Experimental Internet Stream Protocol (ST 2)
THe work at UCB has at least 3 tech reports  on Meta-Scheduling,
UCB TR 90/597 Meta-scheduling for Distributed continuous media - Anderson
TR 90/596 Abstractions for Continuous media in a network window system
          Anderson, Govindan, Homsy
TR 90/599 Implementation Issues for a Network Continuous Media IO Server
                        as above.

These three deal with general issues for synchronous data over packet networks,
as do many, many other papers

Specific to IP, I don't know of any specific papers, other than experimental
efforts to put ST inside IP.

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

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 14:37:38 GMT
From:      acm@ux.acs.umn.edu (Acm)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   TCP-IP source for the AT&T 3B2


Does anyone know where we can get TCP-IP for the AT&T-3B2.  We have 2 3B2
machines that were donated to us (association for computing machinery) by
our most generous department of forestry...without the TCP-IP protocol
OF COURSE. These two machines have ethernet cards and 5 1/4 inch floppy
drives.  If anyone has TCP-IP on a 3B2 floppy format please send it to us.

If you have any brilliant ideas..please contact me at any of the email addresses
mentioned below.

Your help is most appreciated.  Thank you.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
/ ACM@mermaid.micro.umn.edu    |If Your Nose RUNS and Your Feet Smell    \
\ marcus@donald.cs.umn.edu     |You Are Built UPSIDE-DOWN !!             / 
/ marcus@ai.mit.edu            |-----------------------------------------\ 
\ marcus@a.system.near.you     | Yes, My other Terminal IS a Z19 !!      / 
/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 16:21:37 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection


    mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
    > Can copy-protection or license-protection systems such as SCO's be
    > used for a denial-of-service and/or harassment type of attack?

    You need to just look at the format of the udp packets, broadcast the
    same serial numbers from your own ip address, and that should have the
    desired effect of making you extremely unpopular.  

The big question is whether 'cpd' checks the source IP address - if it
doesn't (and the check would have to be complicated due to 0 vs. 1 and
subnet issues), then you can do this from anywhere in the Internet, but
you can only hack one machine at a time.  Of course, you'd need to know
(or probe for) the relevant serial numbers...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 16:26:09 GMT
From:      mbax@ais.org (Mark Baxter)
To:        comp.protocols.tcp-ip
Subject:   Source routing info needed

Can someone provide me with some information on source routing (or a pointer)?

Is source routing implemented at most sites?  
Is there a way to specify source routes in typical unix systems?
If a source route is used to initiate a connection, will it automatically  be
reversed for replies?
Does source routing cause a security problem (ie, one cannot trust an ip
address to connect to a given site)?

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 17:21:44 GMT
From:      nraoaoc@nmt.edu (NRAO Array Operations Center)
To:        comp.protocols.tcp-ip
Subject:   SLIP documents

Where can I get some good documentation on SLIP? I have RFC1055, but it does
not state which of the actual protocols it uses (presumably because it can use
more than one). Now, I thought it used UDP in most implementations, and I'm 
trying to convince someone that he's not getting much, if any, error correction
on his SLIP connections, but he wants actual written proof. He thinks it's 
using TCP (as in "TCP/IP"), the same as Internet connections on Ethernet links.
I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is 
there such a beast?

Our particular implementation is Rayan Zachariassen's streams SLIP for Suns. 
The closest thing I can find in the source code is that it includes the TCP
header definition from /usr/include/netinet/tcp.h if SLIP_FASTECHO is defined
(to give rlogin/telnet better response). But what about ftp? Does that use udp
instead, or does SLIP just use raw IP in this case? And what implications does
that have for error correction?

While enough personal testimonials would help, more formal-looking documents
would be better :-).

Thank you all.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
                            rmilner@zia.aoc.nrao.edu

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 17:30:10 GMT
From:      kwe@bu-it.bu.edu (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25

In article <38836@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes:

> Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip
> Subject: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25
> Date: 4 Feb 91 02:09:29 GMT
> 
> I would like to get opinions on pros and cons for setting up an
> Internet.  The two setups are:
> 
> 1) All sites on the internet have routers that attach to a public
> data network and use TCP/IP to communicate between nodes on the net.
> 
> 2) All sites on the internet connect directly to an X.25 network,
> and any client-server applications between two sites are written
> directly to an X.25 API or to some software abstraction that is
> written on top of X.25.
> 

	The wording is kind of hard to interpret, since I think "site"
is used when "host" might be what is meant, but nonetheless ...

	I would decouple internet issues from application API issues
and loosen up on the "either/or" tone and take an attitude of "one or
more". 

	If I had the choice of APIs to write to for client-server
applications, it would be a session-style API and/or an RPC API that
offers me virtual circuit streams-of-data service, simple unreliable
messaging, and a robust transaction protocol that would be able to run
on TCP/IP or OSI-IP or 802.2 as part of the operating system I was
using.

	If I didn't have an OS that offered me a good session or RPC
API, then I would still write that interface myself and write a lower
level interface to TCP/IP and one to X.25.  Then if I wanted more
transport options in future, I wouldn't have to rewrite my
client-server code, only yet another transport option for my session.

	The idea is to layer intelligently, hide what lower level
information can be hidden, but write the API such that it anticipates
the wide variety of transport services that it might have to use
(connectionless, connection-oriented, high-bandwidth/low-latency,
low-bandwidth/hi-latency, ...).

	As far as internet architectures go, allow for multiple
protocols and overlapping transition periods.  Keep your LAN and WAN
technologies decoupled by using routers or capable bridges.  Design
with multi-protocol hosts and servers in mind.  Give your users
options, not mandates.

	X.25 is a WAN option to use public nets over the use of
private lines, nothing more.  I don't care for it as an alternative
for available LAN technology.  It has been more than four years since
I heard anyone seriously talk about doing that.  :-)

	--Kent

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 17:43:00 GMT
From:      goud@sicsun.epfl.ch (Mireille Goud)
To:        comp.protocols.tcp-ip
Subject:   problem with ftp


I have a problem with ftp :

I noticed that the packets size depends on the address of the hosts :

        - If the 2 hosts are on the same network (same B class
address) the size of the packets is negociated between the 2 hosts.
	
        - If the 2 hosts are not on the same network (they don't have
the same class address) the size of the packets is 512 bytes.

1. Is this a ftp problem or a tcp problem ?

2. Is there a solution to have big packets (4K bytes on fddi) even if
the 2 hosts are not on the same network ?


Thanks.
          Mireille
----------------------------------------------------------------------
Mireille Goud
SIC EPFL
Switzerland                    INET : goud@sic.epfl.ch

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 18:53:48 GMT
From:      hqm@media-lab.MEDIA.MIT.EDU (Henry Minsky)
To:        comp.arch,comp.protocols.tcp-ip,comp.dsp,rec.audio
Subject:   Reed Solomon Code code

Sorry for the wide distribution, but I'm not sure which newsgroup is
appropriate for this query;

I am trying to find source code or descriptions of software (or
hardware) algorithms for Reed Solomon encoding/decoding. Specifically,
I am interested in something which emulates the Cross Interleaved
Reed-Solomon coding found on CDs, and the double encoding found on
CD-ROMS.

Any references (journals, conferences, books) would also be helpful.

Thanks,
	Henry Minsky

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 20:08:31 GMT
From:      bradg@zaphod.UUCP (Brad Gorzitza)
To:        comp.protocols.tcp-ip
Subject:   Two TCP Queries



        I have two tcp questions for this news group.  My  apo-
   logies  if  the  answers appear in the RFC's somewhere or if
   these questions have been  answered  here  before.   Anyway,
   here goes.

        First question: consider the following setup.

    ---------------     -------                  -------    ---------------
    | Application |     | TCP |==================| TCP |    | Application |
    |     A       |+++++|  A  |       Lan        |  B  |++++|     B       |
    _______________     _______    Connection    _______    _______________



        Application A stops accepting data from TCP A.   Appli-
   cation  B  continues sending data via TCP B until TCP A runs
   out of buffers and advertises window of 0.  After  a  while,
   Application B closes the connection.  What should TCP B do?

        According to RFC 793, SYN and FIN are included  in  the
   window (to give them retransmission protection).  Hence, TCP
   B supposedly cannot send a FIN until TCP A opens its  window
   again.   Is  this the case?  If I want TCP B to exit could I
   simply have it do so, perhaps after sending a RST?  Or am  I
   bound by the RFC's to let things run their course?

        Second question: consider  the  following.   TCP  A  is
   sending  data  to  TCP B.  *No* data is being sent the other
   way.

           TCP A                                        TCP B
           -----                                        -----

          send X bytes of data    --->               <received>
          seq # = Y  ack # = Z


              <lost>           <-----            seq # = Z  ack = X+Y


          send X bytes of data    --->               <Old data already
          seq # = Y  ack # = Z                       acked; silently
                                                       discarded>
                   .                .                      .
                   .                .                      .
                   .                .                      .
                   .                .                      .
           <connection reset at this
           end due to no response>


        My question is should TCP B  retransmit  its  ack  upon
   receiving a retransmission of data?


        Anyway, thanks in advance to any and all who reply.  As
   this  might be of interest to others, it might be an idea to
   reply to this newsgroup.

-- 
____________________________________________________________________________
Brad Gorzitza		bradg@zaphod.uucp
Develcon Electronics	"If this is the road we take to our dreams,
Saskatoon, Sask.	 do we walk in vain?"	T'Pau

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 21:08:42 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: summary on transferring motion picture over IP

In article <1991Feb6.140207.25450@bronze.ucs.indiana.edu> Zhen Li <lizhen@silver.ucs.indiana.edu> writes:
>From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston)
>
>Count up the number of pixels in one frame, multiply by the
>number of bits behind each pixel, then compare to the 10 Mbits/sec
>serial bit rate of Ethernet.  I think you'll find a major
>mismatch.

Assuming 1k by 1k pixels per frame, 24 bits per pixel, 30 frames per
second, that's 720 Mbps, apparently about two orders of magnitude off
Ethernet speeds.  However, this is not really a fair comparison.  I think
it is safe to expect that a protocol for real-time digital video
transmission would use compression techniques.  I'm no expert in data
compression, but it seems like it should be possible to get very high
compression ratios for motion pictures.  First of all, within a frame you
can do quite well with techniques based on run-length encoding and/or
extrapolation.  And the differences between successive frames are generally
very small, so I would expect the protocol to only send the changes, rather
than entire frames.  And if the compression algorithm makes use of good
image processing techniques, it could even recognize shifts of the entire
background (very common, due to camera panning) and send a short encoding
to compensate for it, rather than sending all the pixel-by-pixel
differences.  Colors can be encoded in fewer bits, using color maps
(sending only the changes as they occur) and/or Huffman coding.

Of course, all this compression requires lots of compute power.  I'm not
sure it could currently be done in real time, so I don't think you could
put an Ethernet between a video camera and monitor.  However, if the goal
is to allow downloading from a server, this wouldn't be a problem.  The
video could be compressed in batch, and this compressed version would be
stored in the database and downloaded directly to the monitor.
Decompression is generally much easier than compression, so it can probably
be done in real time

There's a guy claiming to have developed technology to send videos over
voice-grade phone lines, which are several orders of magnitude slower than
Ethernet.  He must be using techniques like these, and more.


--
Barry Margolin, Thinking Machines Corp.

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

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 21:35:27 GMT
From:      mcguckin@decwrl.dec.com (Joe McGuckin)
To:        comp.protocols.tcp-ip
Subject:   Multiple modems w- PPP???

Does PPP support a link using 2 or more modems to increase bandwidth
(like the NetBlazer)?


Thanks,

   joe

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Feb 91 22:18:21 GMT
From:      ce1zzes@prism.gatech.EDU (Eric Sheppard)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   NCSA Telnet doesn't like PC-NFS

I've gotten Sun's PC-NFS to work with the Clarkson packet driver. I have 
developed extreme disgust with Sun's Telnet and FTP, so I would like to
use NCSA's Telnet and FTP.  Unfortunately, Telnet and FTP won't work with
PC-NFS.  I get:

Packet Access Type Error 10
Can't access IP handle interface to type 1
Packet driver probably not loaded
Error code: -2

Telnet/FTP with the packet driver works very well when PC-NFS is not active. 
Are Telnet/FTP and PC-NFS doomed to be mutually exclusive?  Is it possible
to get them to cooperate?  If so, how?  I'm using a 3Com 3C503 card on a
286 machine.

Eric

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 00:03:27 GMT
From:      warner@intellistor.com (Dave Warner)
To:        comp.arch,comp.protocols.tcp-ip,comp.dsp,rec.audio
Subject:   Re: Reed Solomon Code code

In <5131@media-lab.MEDIA.MIT.EDU> hqm@media-lab.MEDIA.MIT.EDU (Henry Minsky) writes:

>Sorry for the wide distribution, but I'm not sure which newsgroup is
>appropriate for this query;
 
>I am trying to find source code or descriptions of software (or
>hardware) algorithms for Reed Solomon encoding/decoding. Specifically,
>I am interested in something which emulates the Cross Interleaved
>Reed-Solomon coding found on CDs, and the double encoding found on
>CD-ROMS.

Try Neal Glover's book "Practical Error Correction Design for Engineers."
It was published privately and I don't see an ISBN number but Neal
I think can still be reached at (303)466-5228/5482.  His company
was bought out by Cirrus a while ago but I think the number is still
good.  Excellent book.
-- 
 _____________________________________________________________________ 
 | Dave Warner             | e-mail address: warner@intellistor.com  | 
 | Intellistor, Inc.       | USmail address: 2402 Clover Basin Dr.   | 
 | (303)682-6555           |                 Longmont, CO 80503      | 
 --------------------------------------------------------------------- 

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 00:08:13 GMT
From:      opnrhen@acsu.buffalo.edu (Steve Rhen)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix.sco,comp.unix.xenix.misc,comp.unix.sysv386,comp.unix.sysv286
Subject:   Re: 3c501 users please read this

In article <NELSON.91Feb5145001@sun.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes:
>Sorry to post this so widely, but since the question has come up
>recently twice on the net, and twice locally to Clarkson, people
>should be aware of this problem.
>
>The 3c501 cannot receive back-to-back packets (two packets addressed
>to the same host with no intervening packet).  BSD Unix (well, SunOS
>and NeXTos at least) will attempt to fill your TCP window by sending
>back-to-back packets.  Therefore, your TCP Window must not be larger
>than your TCP MSS.
>
>  o Under KA9Q, use "tcp window 1024" and "tcp mss 1024".
>  o Under SCO Xenix, use the UNDOCUMENTED ifconfig option -onepacket.
>  o Under NCSA Telnet, use "maxseg=1024" and "rwin=1024".
>  o Under FTP Software's PC/TCP, use "ipconfig window 1024".
>

	I've run into situations where it may be necessary to reduce
  the tcp and mss window sizes down as low as 512 to prevent excessive
  retransmits. Many TCP implimentations will use 512 mss packets if they
  think that the packet is leaving the local network. (This is recommended
  based on 576 MTU in gateway requirements in the absense of MTU discovery.)
  With local subnetting and high performance routers two short back to back
  back packets can be generated within the available the the receive window, 
  causing the same poor performance.


Stephen Rhen
University at Buffalo
opnrhen@ubvms.cc.buffalo.edu

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 01:02:53 GMT
From:      kvc@thor.claremont.edu (Kevin V. Carosso)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: UCX and CDCnet problem

In article <12316.27ae98c0@ecs.umass.edu>, ucc@ecs.umass.edu writes:

>We have an elusive problem, where at times, and not always
>on the same node, when a user tries to access the VAXcluster with a
>telnet process from a CDCnet device, (TDI) the user
>gets the message "USER AUTHERIZATION FAILURE", after typing
>in the password.  However the password is correct and not expired,
>or preexpired.

In the past I've had exactly this problem when the client TELNET sends
line-feeds for end-of-line.  Implementations of TELNET client based on the
old Berkeley 4.2 code have a bug when binary mode is negotiated whereby
they end the line with LF instead of CR.  This causes your VMS username
and password to never validate.  This is not noticed on UNIX servers but
for a few editors that run in raw mode and get confused by such clients.

I've not experienced this problem with UCX, but that was because the
broken Berkeley TELNETs have all been replaced around here long before
UCX ever existed.

	/Kevin Carosso
	 Innosoft

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 01:37:50 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip,comp.mail.uucp
Subject:   Are There Standards For Secure Mail Transfer Via SMTP?

Can someone briefly discuss any standards that might exist, or be
in the process of development, for the sending of secure mail via
SMTP or via the Internet.  Also, are there any relevant RFCs on
this topic?

Thanks,
Will Estes        (apple!cup.portal.com!Will)

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 02:55:26 GMT
From:      cabral@lll-crg.llnl.gov (Brian Cabral)
To:        comp.protocols.tcp-ip
Subject:   Looking for a portable IPC subroutine package

[[I'm posting this for my friend Brian who doesn't have convenient access
to the outside world.  Please send replies directly to him.  He'll
summarize back to the group.  Thanks!  Casey]]

I'm looking for a portable (BSD socket based) IPC subroutine package
which will allow me to send a stream of data to multiple processes
(possibly on different machines).  Ultimately these data streams need to
support multiple readers and writers.  I know I can directly do this with
sockets, however the resulting programs that use a hand coded
implementation using sockets would be ugly.  The key is to have a
subroutine interace that is nearly as simple as open, read, write, and
close for multiplexed distributed communication.

						Thanks in advance,
						Brian Cabral

						cabral@lll-crg.llnl.gov

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 03:04:23 GMT
From:      bruce@balilly.UUCP (Bruce Lilly)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   UPS's with EThernet TCP/IP interface for UNIX -- are there any?

There are a number of UPS's available with RS-232 interfaces to initiate
an orderly shutdown of a system upon power failure.  I would much prefer an
UPS with an Ethernet interface, which could be used to initiate orderly
shutdown of several systems. In this way, one would only need one such
intelligent UPS for each independent power source, with other systems
which are being fed from the same source connected to simple UPS's (no
interface). No serial ports would be tied up on any of the machines.

1)	Does such a unit exist (I'm only interested in TCP/IP over Ethernet,
not Brand N network or Brand 3 network or anything else)?

2)	If so, what specific protocol is used? / If not, has anybody developed
a protocol which might be used for this application?

Thanks for any pointers,
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
--
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 03:40:02 GMT
From:      pnessutt@dmshq.mn.org (Bob Monio)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.modems
Subject:   Bi-directional Modems and Terminal Servers


Our organization has recently purchased a Xyplex Terminal Server for
use on our inhouse network.  Because of some problems that we are
currently having with our Telebit and our host, we are thinking about
the possibility of moving the Telebit to the Xyplex and running it
from there.  Has anyone experienced connecting Telebits to Terminal
Servers and if so, could you forward some of the experiences and/or
helpful hints that you may have concerning it?  To be more specific,
we are running a T2500 on a MIPS RC3240 under Risc/OS 4.51.

Any help and/or insight would be appreciated.  Please respond to me
via email.

Thanks!

 -Bob

-- 
 Robert A. Monio                       
 International Quality Institute, Inc.  "Rommel, you magnificent Bastard! 
 pnessutt@dmshq.mn.org                   I read your book!"
 ..uunet!rosevax!sialis!dmshq!pnessutt                -- George S. Patton, Jr.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 14:52:28 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.unix.misc,comp.protocols.tcp-ip
Subject:   Re: Will telnet do VT100 translation for other term types?

>>>>> On 30 Jan 91 16:11:36 GMT, brianop@opac.uucp (BRIAN MCBEE) said:

B> going to buy), but we have people that will be logging in from all
B> kinds of different terminals.  We would then like to be able to
B> telnet from the unix system to a VAX running VMS, and run an
B> application that REQUIRES vt100 terminal emulation.

You can also use the program "vtem", which is somewhere in a
comp.source archive. A newer version, updated by jqj@hogg.cc.uoregon.edu,
is included in in my vttool program (available via ftp on
titan.rice.edu, ~/sun-sources/vttool.shar.?)

This program should run on almost any terminal, and it passed the
vttest program. It does use pty's and is written for berkeley unix.

If you are running X or SunView - the rest of the vttool package 
can provide a window-based panel for clicking function keys your
terminal might not have. It also does keyboard remapping. 
It requires SunView or XView libraries.
--
Bruce G. Barnett	barnett@crd.ge.com	uunet!crdgw1!barnett

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 15:28:39 GMT
From:      klefstad@ux1.cso.uiuc.edu (Sue Klefstad)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with NCSA Telnet 2.3b14

ce1zzes@prism.gatech.EDU (Eric Sheppard) writes:

>I just can't seem to get Telnet to work directly with my ethernet card.
>...
>Particulars:  80286 machine, 3Com 3c503 Ethernet card.  Also installed

I second the recommendation to use the Clarkson packet drivers.
Telnet 2.3bxx is supposed to work directly with the 3c503 card
but I've yet to find a machine in which it does.

-- 
-- Sue
--
=========================================================================
Sue Klefstad    Ill. Natural History Survey    klefstad@uiuc.edu

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 16:46:14 GMT
From:      martino@logitek.co.uk (Martin O'Nions)
To:        comp.protocols.tcp-ip
Subject:   Re: LM/X and RFC1001

whwb@ciba-geigy.ch (Hans W. Barz) writes:

>Since we are interested in LM/X I tried to find out, who has really
>implemented the RFC1001 correctly. RFC1001 has some nice mechanism build in to
>avoid broadcast over internets. The interface on the 'otherwise broadcasting'
>client sends a request to the domain server instead. New servers announce
>their server capabilities to the domain server as well - this is kind of a new
>feature for DNS (interactive update from client).
 
>As a matter of fact no one seems to have implemented it. Only Ungermann/Bass
>seems to have plans to do it and they are also delivering an interface to LAN
>Manager.
 
>Has somebody more information on that ?

I could be wrong, but if I remember correctly, RFC1001 does allow for only
a subset of the three transmission types to be implemented (although the
usefulness of such a system could be questioned). A recent post stating that
Hewlett-Packard's implementation worked across different logical IP networks
would appear to imply that HP do provide the Datagram and Name Service
handlers necessary for P and M type topologies - it was on this point that
our attempts to link 3Com's RFC NetBIOS LAN Manager server, and SCO's ODT
client failed, despite attempts to configure a NetBIOS agent. We still
don't know if either of the implementations supports the agent, or if
we simply couldn't find out how to use it properly......

I look forward to a full implementation from somebody.

Martin

--
DISCLAIMER: All My Own Work (Unless stated otherwise)
--------------------------------------------------------------------------
Martin O'Nions            Logitek Group Support      martino@logitek.co.uk
--------------------------------------------------------------------------
      Auntie did you feel no pain / Falling from that willow tree?
     Could you do it, please again / 'Cos my friend here didn't see.
         (Harry Graham - Ruthless Rhymes for Heartless Homes)

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 17:34:48 GMT
From:      kwe@bu-it.bu.edu (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Compressed Video Transport Requirements

> From: barmar@think.com (Barry Margolin)
> Newsgroups: comp.protocols.tcp-ip
> Subject: Re: summary on transferring motion picture over IP
> Date: 6 Feb 91 21:08:42 GMT
> 
> I think
> it is safe to expect that a protocol for real-time digital video
> transmission would use compression techniques.  ... within a frame you
> can do quite well with techniques based on run-length encoding and/or
> extrapolation.  And the differences between successive frames are generally
> very small, so I would expect the protocol to only send the changes, rather
> than entire frames.  And if the compression algorithm makes use of good
> image processing techniques, it could even recognize shifts of the entire
> background (very common, due to camera panning) and send a short encoding
> to compensate for it, rather than sending all the pixel-by-pixel
> differences.  Colors can be encoded in fewer bits, using color maps
> (sending only the changes as they occur) and/or Huffman coding.
> 

	I was impressed by Van Jacobson's 40-to-1 compression of TCP,
using detailed information about the structure of TCP.  I'm sure that
something similar is possible for video sequences, using detailed
information about the structure of video.

	The fascinating thing to me about compressed video is that
real-time compressed video transfer dynamics will probably be nothing
like uncompressed video or voice data streams.  What is the maximum
instantaneous bandwidth required to support these efficient real-time
compression techniques?  Do efficiently compressed video datastreams
require reliable transport or minimum latency variation?  What maximum
latency and delay variance can they accept and still work acceptably
in real time?  What effect does lossage or error have on the final
image?

	I would be interested in leads to research on what expected
real-time compressed video technology will minimally demand of the
underlying network.  Does efficiently compressed video still require
ST, for instance?

	--Kent

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 17:35:36 GMT
From:      dahl@SRC.Honeywell.COM (Peter Dahl)
To:        comp.arch,comp.protocols.tcp-ip,comp.dsp,rec.audio
Subject:   Re: Reed Solomon Code code

In article <1991Feb7.000327.15642@intellistor.com> warner@intellistor.com (Dave Warner) writes:
>In <5131@media-lab.MEDIA.MIT.EDU> hqm@media-lab.MEDIA.MIT.EDU (Henry Minsky) writes:
 
>>I am trying to find source code or descriptions of software (or
>>hardware) algorithms for Reed Solomon encoding/decoding. Specifically,
>>I am interested in something which emulates the Cross Interleaved
>>Reed-Solomon coding found on CDs, and the double encoding found on
>>CD-ROMS.
 
>Try Neal Glover's book "Practical Error Correction Design for Engineers."
>It was published privately and I don't see an ISBN number but Neal
>I think can still be reached at (303)466-5228/5482.  His company
>was bought out by Cirrus a while ago but I think the number is still
>good.  Excellent book.

Also try this one: "Error-Control Coding for Computer Systems", T. Rao and
E. Fujiwara, Prentice-Hall, 1989, ISBN 0-13-283953-9.  This has a good
description of RS coding, but not the discussion is not specific to CDs
so you may have to figure it out.

peter dahl@src.honeywell.com
I had fun once, and it wasn't anything like this

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 18:48:26 GMT
From:      jnford@handlebar.weeg.uiowa.edu (Jay Ford)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents


In article <1991Feb6.172144.12605@nmt.edu>, nraoaoc@nmt.edu writes:
|> Where can I get some good documentation on SLIP? I have RFC1055, but it does
|> not state which of the actual protocols it uses (presumably because
 it can use
|> more than one). Now, I thought it used UDP in most implementations, and I'm 
|> trying to convince someone that he's not getting much, if any, error
 correction
|> on his SLIP connections, but he wants actual written proof. He thinks it's 
|> using TCP (as in "TCP/IP"), the same as Internet connections on
 Ethernet links.
|> I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is 
|> there such a beast?

SLIP does not "use" any transport or application protocols.  SLIP simply
provides a way to transmit IP traffic over a serial line.  In effect, it gives
you a link layer over a serial line functionally similar to that provided by
Ethernet for use on coax (or fiber, or twisted pair, or microwave...).  Once
you have a working link layer to run IP over, you can run any transport (UDP,
TCP, etc) over IP on that link.  The upper layers don't care what the medium
is.  That's the point of a layered approach to networking!

Applications use whatever transport protocol is appropriate, independent of
the link layer.  TELNET, FTP, SMTP and others use TCP;  NFS, DNS, and others
use UDP.

Basically, the only difference you should see between an Ethernet Internet
connection and a SLIP Internet connection is the speed and throughput.

------------------------------------------------------------------------
Jay Ford, Weeg Computing Center, University of Iowa, Iowa City, IA 52242
jnford@handlebar.weeg.uiowa.edu, 319-335-5555

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 18:54:54 GMT
From:      tjs@MSC.EDU (Tim Salo)
To:        comp.protocols.tcp-ip
Subject:   Re: Pros/Cons of TCP+Router vs. X.25

> However, the original question did not indicate whether the proposed 
> solution was a public X.25 network or a private X.25 network.  

I am about to stand corrected, (the proposed solution was a public X.25
network).

> If the proposed solution is a private, (rather than public), X.25 network,
> then per-packet charges are most likely not an issue.

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 19:16:11 GMT
From:      karl@lvs.Eng.Sun.COM (Karl Auerbach)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25

In article <38836@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>I would like to get opinions on pros and cons for setting up an
>Internet.  The two setups are:
>
>1) All sites on the internet have routers that attach to a public
>data network, like UUNET's Alternet, and use TCP/IP to communicate
>between nodes on the net.  To the extent that X.25 might be used
>underneath TCP between the routers, this is invisible to the
>applications.
>
>2) All sites on the internet connect directly to an X.25 network,
>and any client-server applications between two sites are written
>directly to an X.25 API or to some software abstraction that is
>written on top of X.25.
>
>What are the advantages to either approach?  Clearly 2) is going
>to be more efficient since you don't have the extra error-checking
>of TCP and you don't have the extra data bandwidth of the router
>headers being attached to each packet.  This advantage aside, are
>there any decisive advantages that argue for approach 1)?

Don't bet on approach #2 being automatically more efficient.  A router
can run a number of parallal X.25 connections and spread the traffic
across those.  (You may find some X.25 providers will constipate a
given X.25 virtual circuit well before you exhaust the interface
circuit bandwidth, so by using multiple VCs you can push more
packets.)

And I doubt that you will reach data rates over the typical X.25 (or
TCP or OSI over X.25) that will even begin to make the TCP/IP or OSI
checksumming, etc increase to a noticable level.  (This is not to say
that some networks may offer high performance X.25 service.  It's just
that most of the providers that I see don't.  If they did then your
overhead concern would begin to be meaningful.  But I suggest that you
might find that the burden of dealing with X.25, even at low data
rates, greatly exceeds the cost of TCP/IP or OSI connectionless
network and transport layer.)

Approach #1 will give you more portable code (assuming you are
programming to a fairly standard interface like "sockets".)

				--karl--

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 20:48:16 GMT
From:      nsayer@uop.edu (Nick Sayer)
To:        comp.protocols.tcp-ip
Subject:   How widespread is RFC931 on the internet?

We've just put in an RFC931 authd daemon on our system.
Some experimental connection attempts to other sites'
auth ports resulted in refused connections, which
leads me to believe that not many sites have authd
set up. Is this the case?

For those of you unfamiliar with the concept, it allows
a system on one end of a TCP stream to ask the system
on the other end what user (by user ID string) is
responsible for the stream. For example, if a user
telnets to some site and manages to break into someone's
account, a record could be made not only of the site from
where he came, but the account he came from. This
makes the potential audit trail a little easier to
follow.

I am considering hacking the in.telnetd at our site
so that it will insist on having authd set up at
sites telneting in, but if not many sites have an
auth daemon running, there's not much point.

-- 
Nick Sayer               | Disclaimer: "Don't try this at home, | RIP: Mel Blanc
mrapple@quack.sac.ca.us  | kids. This should only be done by    |   1908-1989
N6QQQ  [44.2.1.17]       | trained, professional idiots."       |  May he never
209-952-5347 (Telebit)   |                     --Plucky Duck    |  be silenced.

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 21:47:07 GMT
From:      madams@ecst.csuchico.edu (Michael E. Adams)
To:        comp.protocols.tcp-ip
Subject:   have you compiled NCSA Telnet w/Turbo C?

I won't waste your time detailing the aggravation I
experienced sorting out the tel23src.zip rats nest of files
from NCSA.

Still, I would love to hear from anyone who has successfully
compiled the Telnet programs with Turbo C.

The idea that I'm wasting my time on a dead end project really
makes me ill.  Just knowing it "has" be done would be comforting.

-Thank you for your support.

         (___)      |  Michael E. Adams
         (o o)      |  Custom Computer Programming
  /-------\ /       |  P.O. Box 5027
 / |     ||O        |  Chico,  California  95927-5025    U.S.A.
*  ||,---||         |
   ~~    ~~         |  internet: madams@cscihp.ecst.csuchico.edu
No BULL bandwidth   |

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Feb 91 23:51:37 GMT
From:      alex@sapphire.idbsu.edu (Alex Feldman)
To:        comp.protocols.tcp-ip
Subject:   UDP (RFC 768)

I have read RFC 768, but I don't understand the psuedo header, viz:

Is UDP Length in the psuedo header the same as Length in the header?
If so, why do that, and if not, what is the difference?

Is the protocol field always 17?  Again, why bother or what else is
it?

Why the source IP address?  Help.

	--alex		alex@opal.idbsu.edu


-- 
	--alex			alex@opal.idbsu.edu

Boise State University doesn't have any opinions.  Therefore, these are 
not the opinions of Boise State University.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 01:30:20 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection

>     You need to just look at the format of the udp packets, broadcast the
>     same serial numbers from your own ip address, and that should have the
>     desired effect of making you extremely unpopular.  

jbvb@FTP.COM (James B. Van Bokkelen) writes:
> The big question is whether 'cpd' checks the source IP address - if it
> doesn't (and the check would have to be complicated due to 0 vs. 1 and
> subnet issues), then you can do this from anywhere in the Internet...

??? Isn't it possible to forge the source IP address to be a random
node on the same subnet as the victim?  The destination certainly won't
be sending any responses back....

On the other hand, don't most routers across the Internet disable
directed broadcasts?

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

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 01:34:00 GMT
From:      CCO1376@mvs.draper.COM
To:        comp.protocols.tcp-ip
Subject:   SUBNET DIRECTED BROADCASTS


We have discovered a problem on our network and would like to know if
other sites have seen this problem.  Solutions will be cheerfully
accepted, also.

We are running a subnetted class B network with a mixed bag of PCs,
workstations, minis and mainframes: IBM, Apple, Sun, HP, DEC, etc.  In
order to better localize broadcast traffic to the originating subnet, we
have configured most of this equipment to use the Subnet Directed
Broadcast address: {<network number>,<subnet number>,-1} as described in
RFC 1122, Section 3.3.6.

Due to the need to support B-node NETBIOS over TCP (ala RFC 1001, 1002),
the PCs using this protocol use the All-Subnets Directed Broadcast
address: {<network number>,-1,-1}.  Since our routers (Wellfleet) will
pass All-Subnets Directed Broadcasts, we are able to provide the
connectivity required for this service.  Note, the routers themselves
use Subnet Directed Broadcasts for RIP.

So far, so good.  We did notice, however, that there was a large number
of ICMP Destination Unreachable (Port Unreachable) messages being
generated.  We traced this activity to the ULTRIX, UCX, AIX, A/UX, and
OS/2 (but not SunOS) systems responding to the UDP All-Subnets Directed
Broadcast from the NETBIOS machines.  Apparently a lower layer of
software in these machines accepts this traffic and passes it to a
higher layer that is then unable to recognize it as a broadcast.  It
would seem that, recognizing the broadcast nature of the message, the
higher layer should drop it quietly.  (Imagine all hosts on a network,
except one, responding to ARP with "not me" messages.)  :-)

One supporting piece of evidence of the underlying pathology is that the
offending machines can be silenced by configuring them to use
All-Subnets Directed Broadcasts, but that then loses the advantage of
localizing these broadcasts.  Furthermore, these offending machines now
complain about the RIP packets, which use Subnet Directed Broadcasts.

Reading in RFC1122 is enlightening.  First, referring to the above
mentioned broadcast address definitions in Section 3.3.6 it says, "A
host MUST recognize any of these forms in the destination address of an
incoming datagram."  Earlier, in Section 3.2.2 it says, "An ICMP error
message MUST NOT be sent as the result of receiving: ... a datagram
destined to an IP broacast or an IP multicast address, ..."  Lest there
be any misunderstanding, it goes on to say, "THESE RESTRICTIONS TAKE
PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING
ICMP ERROR MESSAGES."

The subsequent "discussion" goes on to describe the *exact* problem we
observed, that is, a UDP broadcast to a non-existent port that triggers
a flood of ICMP Destination Unreachable datagrams!

------------------------------------------------------------------------
Cecil C. Ogren             cogren@draper.com
C.S.Draper Laboratory      (617)258-1655
555 Technology Square
Mail Station: 33
Cambridge MA 02139
------------------------------------------------------------------------

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 01:59:33 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25

Will Estes--

Although I could, if I were willing to risk the Wrath of Postel, offer
a semi-reputable definition of "datagram" that would render the notion
of "reliable datagram" non-oxymoronic, even I know of no definition of
"Internet" that would salvage the notion of an X.25-only Internet.  Indeed,
by definition an X.25 communications subnetwork is a single net, not
an inter-net; that is, "Internet" is not a contraction of "intercomputer
network", it's a replacement for the earlier, but apparently too subtle,
term, "catenet" (originally meant to convey a concatenation of sundry
individual/single comm subnets).

On second thought, considering what happened to the term "gateway" once
the heffalumpers got at it, perhaps I should say that "Internet" was
never INTENDED to be a mere contraction for "intercomputer network", though
IFF it were used in that solecistic sense I suppose your second alternative
would at least be lexically licit.  It would still be a bad idea, however,
since it's precisely to allow Host computers attached to various/"all"
comm subnet "technologies" to interoperate that the proper sense of Internet
(and Catenet before it) was invented for--and it's precisely that breadth
of attachment options which X.25 precludes, almost by definition and
certainly in practice (since even "X.75"'s presence to connect independent
X.25 instances does not cover the very common case of Local Area Networks
which are not attached to via X.25, Host-to-LAN; thus, there can't/couldn't
be a REAL X.25 Internet until and unless the world went mad enough to force
LANs to present almost utterly inappropriate to LAN interfaces).

cheers, map

P.S.  Lest any of the usual X.25 apologists be tempted to argue that
X.25 SHOULD be the required interface to all LANs, I'd observe that
such matters should only be discussed on the CCITT1996 and/or CCITT2000
mailing lists, not here--and I'd wish them the best of luck in getting it
adhered to even if they do get it voted for....
-------

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 02:19:44 GMT
From:      merlin@sulaco.Sigma.COM (David Hayes)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25

One question which I have not seen addressed is the cost of the media.  
X.25 lines are typically charged by the (X.25) packet.  Therefore, your
monthly cost can vary widely, depending on how much data is sent.  All
of the present IP network providers sell you a pipe of a given size,
say, 56k bits per second, for a flat rate regardless of actual usage.

	David Hayes

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 02:22:56 GMT
From:      goldstn@evax.arl.utexas.edu (David Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Problems with heterogeneous networks

For quite some time I've been unable to debug TCP/IP code that behaves
as follows:

sockets are used to communicate at port #2700. the same code is used on
each machine.

sun4 -> sun4 fine
sun4 -> sun3 fine
sun3 -> sun4 connects properly, but sending gets bad address on the Unix
		"write"..
		seems as if the socket # is correct though
sun3 -> sun3      "
VAX (Ultrix) and Sun4 -> does not connect

Can anyone give me some insight  on this problem?  Enclosed is some of
the relevent source code, loaded with print statements for debugging.
Thanks very much for even reading!
David


/**********************************************************************
   Name:  Setup sockets

 Abstract:  This routine sets up sockets for the interactive
     workstations.  The white workstation connects at a reserved
     port.  A server port is set up for the other workstations.
     The ports are set to be non-blocking so that an "accept"
     can be done in a loop without hanging.

 
  Revision History:
    06/06/90    D. Goldstein	 
***********************************************************************/
#include <sys/types.h> 
/* #include <sys/socket.h>  */
#include <stdio.h>
#include <netinet/in.h> 
/* #include <netdb.h> */
#include <errno.h>
#define SETUP_SOCKETS
#include <ctype.h>
#include "my_sockets.h"
#include "tcmipc.h"
#include "icm.h"
#include "stats.h"
#define TRUE 1
#define FALSE 0
/*
extern int have_told_tcm_quitting;
*/
extern long int timer[20];



/* Make a socket and listen for connections */
int make_server_socket(serv_port)
int serv_port;              /*  server port  */
{
extern struct hostent *gethostbyname();
struct hostent *rhp;
int s, on =0;
struct sockaddr_in raddress;

    s = socket(AF_INET, SOCK_STREAM, 0);
    if (s < 0) give_error("socket in make_server_socket");

    /* look up address of the destination machine */
    if ((rhp = gethostbyname(my_host_name)) == NULL) 
	give_error("gethostbyname make_server_socket");
    bzero((char *)&raddress, sizeof(raddress));
    bcopy(rhp->h_addr,(char *)&raddress.sin_addr,rhp->h_length);
 
    raddress.sin_family =  AF_INET;
/*    raddress.sin_addr.s_addr =  INADDR_ANY; */
    raddress.sin_port = serv_port;         /* server port */
    if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) < 0) 
	give_error("setsocketopt in make_server_socket");

    if (bind(s, (struct sockaddr *) &raddress, sizeof(struct sockaddr_in)))
	give_error("bind_socket");
    if (listen(s, 10) < 0) 
 	give_error("listen make_server_socket");
   return(s);
}


look_for_host(i,count)
int i,count;
{
struct hostent *hp;
extern struct sockaddr_in Host_addr;
extern struct hostent *gethostbyname();
int sock;

   printf("Establishing connection to workstation on host |%s|\n",ws[i].name);
   hp = gethostbyname(ws[i].name);
   if (hp == (struct hostent *) 0) give_error("gethostbyname");
   /* Get local host address */
   bzero((char *)&Host_addr, sizeof(Host_addr));
   bcopy(hp->h_addr, (char *)&Host_addr.sin_addr, hp->h_length);
   Host_addr.sin_family = AF_INET;
   Host_addr.sin_port = ws[i].adrs;
   printf("will accept %s at #%d\n",ws[i].name,ws[i].adrs);
   if ((sock=socket(AF_INET,SOCK_STREAM,0))<0) give_error("socket");
   while (connect(sock,(struct sockaddr *)&Host_addr,sizeof(Host_addr))<0);
   printf("%s connected %d = TRUE at socket %d\n",ws[i].name,i,sock);
   connected[i] = TRUE;
   who_head = insert(ws[i].name,who_head,sock,TCP);
   return(sock);
}



b4accepting(i,count)
int i,count;
{
    sock[i] = make_server_socket(ws[i].adrs);
    if (dont_block(sock[i]) < 0) perror("Creating non-blocking pilot socket");
    fprintf(stderr,"%s: B4listening, listening for %s at socket# %d.\n", 
               my_host_name,ws[i].name,ws[i].adrs);
}

accepting(i)
int i;
{
int g;
    g = accept(sock[i],0,0);  /* modifies a copied socket */
    if (g > 0) {
       sock[i] = g;
       fprintf(stderr,"%s: Connected at socket # %d: %s\n",
              progname,g,my_host_name);
       if (dont_block(sock[i])< 0) perror("Resetting non-blocking attributes");
       connected[i] = TRUE;
       who_head = insert(ws[i].name,who_head,sock[i],TCP);
       printf("connected  to proc %d= TRUE, %s uses socket %d\n",
                    i,ws[i].name,sock[i]);
       }
    else if ( g < 0 && errno != EWOULDBLOCK) {
            fprintf(stderr,"%s: Error connecting %s\n", progname,my_host_name);
            perror("accepting connection");
            }
	 else { sleep(1);
              printf("in never-never land?\n"); /*  Terminate(1);  */
              }
}


setup_sockets(count,vars)
int count;
char *vars[];
{
int length,msgsock, connecting=0;
struct sockaddr_in server;
int g,i,j,c, iterat = 0;
struct hostent *hp;
extern struct sockaddr_in Host_addr;
extern struct hostent *gethostbyname();
extern give_error();

    /* NOTE: all 'C' arrays are 0-based, but command-line args 1-based,
       hence arrays are indices are compensated for */

    last_ws = count;
    gethostname(my_host_name,HOST_NAME_LENGTH);
    printf("Hostname is %s of %d workstations\n",my_host_name, last_ws);

    for (i=0; i<last_ws; i++) 
        if (strcmp(ws[i].name,my_host_name)<0)
           b4accepting(i,count);
/*
    printf("\nHit 'C' to continue.\n");  while ('C' != getchar());
*/ 
    printf("Will start in 10 seconds....hurry up other machines!\n");
    sleep(10);
    /* Handle case of all < self, create and accept socks */
    while (connecting<last_ws) {
          iterat++;
          for (i=0; i<last_ws; i++) 
              if (!connected[i])
                 if ((strcmp(ws[i].name,my_host_name)<0)) {
		    /* printf("going to accepting\n"); */
                    accepting(i); 
                    if (connected[i]) connecting++;
	            }
                 else if (strcmp(ws[i].name,my_host_name)>0) {
			 /* printf("look for host\n"); */
                         sock[i]=look_for_host(i,count);
                         if (connected[i]) connecting++; else sleep(1);
			 }
          if (!(iterat%10000)) printf("can't form a connection\n"); 
          }
    printf("exiting setup sockets");
    fact_message.type = FACTS;
    fact_message.num_facts = 0;
}

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 04:11:35 GMT
From:      morrison@cs.uiuc.edu (Vance Morrison)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Beta testers from PCroute 2.2 needed



                  Call for Beta-Testers for PCBridge

I have just completed the next version (2.2) of PCRoute and now need
beta testers to help exercise the new features.

For those who don't know PCroute is a simple but very useful piece of
software that can convert a IBM-PC with networking cards into an IP 
router.  Thus it is possible to assemble for under $1000 a router that
has performance like commercial routers costing $5000 or more.

Since Version 2.0, I have not had the equipment or time to do very
much with PCroute.  Nevertheless, I was able to add some things
that were needed and relatively easy to do.   In particular

    Support for the WD8003EBT and WD8013EBT cards.      
        These cards have more buffer memory, so they will not
        exhibit the problem with NFS that can be a problem with
        the WD8003E card.  Also the WD8013 is a 16 bit card and
        should speed up packet forwarding 2-4 times over the
        WD8003E card.

    Packet Driver Support
        Packet drivers allow PCroute to use a variety of ethernet
        boards besides the WD800X family.  Performance is not as
        good, but if you are on a tight budget and have old ethernet
        cards handy, it is likely you can make PCroute run with
        what you have.

    New serial code.  
        Although the code has changed significantly, the outside
        effects are minimal at his point.  Basically the only new
        features is the ability to handle > 2 serial interfaces
        and the ability to do CTS-RTS hardware flow control (useful
        if you are using smart modems that do compression).  This
        new code also is designed to make adding PPP, compression
        or synchronous support easy.

The beta-test software is available on accuvax.nwu.edu (129.105.49.1)
in the directory pub/pcroute/exp.  The files are called
pcroute2.2b.tar.Z and pcroute2.2b.src.tar.Z and are compressed TAR
archives.   Please remember this is BETA test code.  It should work,
but may not.  If you are inexperienced in networking or PCroute,
you may want to use the old version or wait a couple of weeks until
we have more confidence that everything works as it should.

If you are going to beta-test this software please let me know.  Also
I am interested in any feedback on the software as well as the documentation.
So don't be shy.  Please send your feedback to morrison@accuvax.nwu.edu.

I wanted to add support for a 56K synchronous board, but I have neither
the hardware or the information needed to write the code.  If anyone
out there wants this capability badly enough to invest a small amount
of hardware/money I could probably write it in about 1 month.


Vance Morrison

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 05:18:04 GMT
From:      KOEHLER@awiwuw11.wu-wien.ac.at (Wolfi)
To:        comp.protocols.tcp-ip
Subject:   Loooking for lpd for DOS w/packet drivers

Has anyone seen a public domain version of the UNIX lpd program as an
implementation on a DOS PC which works together with packet drivers and/or PC/T
CP from FTP Software ?
Please send me a note.
Many thanks in advance.

Wolfgang Koehler (Koehler at AWIWUW11.BITNET)
Computer Center
University of Economics and Business Administration
Vienna, Austria, Europe

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 08:25:04 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re: Pros/Cons of TCP+Router vs. X.25

you cannot say "public X.25 networks charge per packet":

all of them are different in their charging structures. Most charge by packet,
some add connection establishment charges, some have additional connection
duration charges, some have distance dependent charges some all of the above,
some have flat rates per month. PLEASE: if YOU YOURSELF did not enquiredo
net disseminate incorect information!



michael

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 08:34:50 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: How widespread is RFC931 on the internet?

In article <27b1bd10.20dc@uop.uop.edu> nsayer@uop.edu (Nick Sayer) writes:
>We've just put in an RFC931 authd daemon on our system.
>Some experimental connection attempts to other sites'
>auth ports resulted in refused connections, which
>leads me to believe that not many sites have authd
>set up. Is this the case?

Seems pretty likely.  Authd may not be trivial to implement without
modifying the TCP implementation.  For instance, on BSD Unix it would have
to grovel through the kernel's socket table, then search through all the
process file tables looking for references to the socket; also, more than
one process may have the same socket open, and the processes may be running
under different userids, so it's not clear which userid should be returned.

>I am considering hacking the in.telnetd at our site
>so that it will insist on having authd set up at
>sites telneting in, but if not many sites have an
>auth daemon running, there's not much point.

I think this idea is misguided.  The RFC931 protocol is extremely insecure;
if the remote host isn't secure, the returned information isn't very
reliable.  This is probably another reason why no one implements RFC931.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 09:59:53 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re:  When is a link saturated?

Up to recently, my opinion was that slower interfaces should have larger
amount of buffers in their output queues (or that a minimum reserved number
should be defined with a scheme for picking additional ones from a common
pool using up unallocated memory).
Now I read from Cisco's doc: "For slow links, use a small output queue
hold limit.". The only reason I see is avoiding retransmissions making the
congestion problem worse with duplicate packets. But I am not sure that,
as soon as a buffer of a congested small output queue becomes free, the next
datagram to fill it will not be retransmission anyway.
What is true? Are routers able to use techniques to match retransmissions
waiting in an output queue and discard the duplicate of a waiting datagram?

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 10:57:21 GMT
From:      leo@unipalm.uucp (E.J. Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: 32 bit ethernet adapters

rpinder@phad.hsc.usc.edu (Rich Pinder) writes:

>I'm looking for a 32 bit, Micro-Channel, Ethernet adapter, that has
>(working) drivers for SCO.
 
>I'd appreciate any leads.  (I know about Cogent - drivers lacking)
 
>thanks
 
>		Rich Pinder
>		USC School of Medicine
>		(213) 342-1640
 
>		rpinder@usc.edu
 
>    ||||||||||||||||||||||||||||||||||||||||||||||||||
Try Trend Datalink (Torus Division)
Unit 208
Cambridge Science Park
Milton Road
Cambridge 
United Kingdom
+44 223 423131
for a blindingly fast MCA card: Definitely SCO Unix support. Good stuff.

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 11:03:17 GMT
From:      leo@unipalm.uucp (E.J. Leoni-Smith)
To:        comp.protocols.tcp-ip,comp.mail.uucp
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?

Will@cup.portal.com (Will E Estes) writes:

>Can someone briefly discuss any standards that might exist, or be
>in the process of development, for the sending of secure mail via
>SMTP or via the Internet.  Also, are there any relevant RFCs on
>this topic?
 
>Thanks,
>Will Estes        (apple!cup.portal.com!Will)

Do you mean secure as in - 'I know the guy got it', or secure as in 
'if someone else got it they need 20 years on a Cray to decrypt it?'

Surely encryption/decryption of data is not a tcp/ip issue?
Or is it.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 11:16:25 GMT
From:      cliffb@isavax.isa.com (cliff bedore*)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the voltage spec for thinnet?

In article <1991Feb6.033424.21632@usenet.ins.cwru.edu> jb@falstaff.mae.cwru.edu (Jim Berilla) writes:
>In article <1991Feb5.131333.2047@isavax.isa.com> cliffb@isavax.isa.com (cliff bedore*) writes:
>>In article <1991Jan30.155606.21529@dartvax.dartmouth.edu> wbc@moose.dartmouth.edu (Wayne B. Cripps) writes:
>>>
>>>
>>>What should the voltage be on thinnet? - I get readings of
>>>-1.8 to -2.0 volts and .2 to .3 volts - is this in the
>>>range?  is 1.2 volts ok?
>>>
>>>	Wayne
>>
>>At the risk of stepping into something soft and gooey, I thought I'd put on
>>my engineers hat for a while and comment on this.  
>>
>>First.  It will be very traffic dependent (assuming you're using a voltmeter
>>that does some averaging).
>
>True.  Don't use a voltmeter, use an oscilloscope.  You'll see many interesting
>things.
>
>>Having stated that and not knowing the details of an ethernet board, but
>>knowing something about transmission lines, we can get a wag of ranges for
>>the voltages.
>
>Not true.  The voltages on the ethernet are clearly defined.

I didn't say they weren't clearly defined.  I said we could get a range of
what was reasonable.  We engineers call this a worst case analysis.

>
>>The lines are 50 ohms and are terminated in 1/4 or 1/2 watt resistors. (Mine
>>is cause I did it myself and haven't had problems).
>>
>>Power (watts) = voltage ^2 / resistance or
>>
>>voltage = sqrt( power * resistance)
>>
>>voltage = sqrt ( 1/4) * 50 ) or 3.5 volts. for 1/4 watt power
>>
>>voltage = sqrt ( 1/2 * 50 ) or 5 volts for 1/2 watt power
>
>What *are* you talking about?  (And take off that silly hat.)
>In the case of ethernet, the voltage depends on the amount of current
>pulled out of the tap.  It's independant of the power rating of the
>terminating resistors.  Remember that the tap appears as a 25 ohm load,
>i.e. it's connected to two 50 ohm transmission lines.
>

What I am talking about is how much voltage you can put through a 1/4 watt
50 ohm resistor without exceeding its power limits. Not circuit impedance!
The above analysis is true.  If you put 2 50 ohm 1/4 watt resistors in parallel,you get a 25 ohm 1/2 watt resistor.  This reduces the resistance but keeps
the power dissipation the same so the maximum voltage will be the same. 
(Ohms Law; He was a hero to us engineers)  The 2nd calculation was assuming
the specs call for 1/2 watt terminators.  The idea of this was to get an
idea of what would be the max voltage you should see on an ethernet line
using a voltmeter.  Given that the above calculations do that, I'll keep my hat on; thank you very much.

The point is sometimes circuits don't pull current, they get pushed
voltage.  If the voltage-current combination (power) exceeds the rating of
the resistor, it will burn up. If you think this isn't important get a 50 ohm resistor (47) from Radio Shack and plug it into your 110 outlet (but wear eye 
protection and gloves). Or run 15-20 volts down your thinnet and be prepared
to look for a new job

>For the AM7996 transceiver (common in a lot of Sun's), the voltages are
>specified as follows:  High level is between 0 and -.1 volts, low level
>is between -1.625 and -2.2 volts.  As stated above, this voltage is
>generated by a current sink (to -9V) by the chip.  An ideal current sink
>has infinite impedance, and doesn't load the transmission line.  If two
>or more stations transmit at the same time, the voltage on the line goes
>below -2.2 volts.  The chip detects collisions on this basis.

Had you been as quick to answer the original question as you were to
critcize my answer, we could have saved a lot of bandwidth on the net.  I
waited 4 days to see if someone would post an answer.  Since no one did, I
gave the above estimate of what would be reasonable.  

.
.
>      Jim Berilla / jb@falstaff.cwru.edu / 216-368-6776
>"My opinions are my own, except on Wednesday mornings at 9 AM,
>           when my opinions are those of my boss."

In spite of my above comments, I do appreciate knowing what the true
voltages are for ethernet.  I've filed them away for the next time the
question comes up.

Cliff

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 11:34:04 GMT
From:      leo@unipalm.uucp (E.J. Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: copy protection


As a director of a company taht makes its entire revenue from reselling (mainly
TCP/IP) software, I think I have some valid input:-

	1/. If it were just the odd copy, at the odd educational site -
	no problem.

	2/. The worst offenders are large corporates and small dealers.

	3/. I have been on a site where 100 users were running software
	supplied by us on a 20 copy licence basis - we were unable to
	'prove' this legally - since by the time we contacted the user
	'officially' he declared that the 'software was faulty and had been
	thrown out'. Sideways contact into the company indicated that
	this was not the case....

	4/. Software Piracy cost the end user. Particularly the small end
	user. If every copy of Wordstar in use was paid for, I reckon they 
	could knock it out at about $50 per copy.

	5/. I LIKE the way SUN chose to copy protect PC-NFS - you can 
	copy as many times as you like - you just can't get two copies up
	on the same LAN simultaneously.

	6/. I have come late into this discussion (news only just up inhouse)
	but if SCO are using the same mechanism  - good luck.

	7/. I am also definittely in favour of the scheme that a company called
	Phase II in boston use - to limit either( customers choice) total 
	number of logins allowed OR concurrent users. This seems a very
	fair way.

SOMEONE has to pay for the man years invested in software: Network policing
sreems a very good way of ensuring that people only use what they have 
contracted to use, and that inadvertent over use of a product results
in clear signalling of that fact.


I would welcome any solution that ensures that :-

	(a) Thew customer is not penalised by any copy prootection scheme
	in any way.

	(b) Unless he knowingly or unknowingly exceeds the USE TO WHICH
	HE HAS CONTRACTED WITH THE VENDOR.

That is the crux: If a copy protection makes the product (effectively and/or
practically) unuseable, then people will not buy it.

Conversely if it is widely copied, the only way the vendor and manufacturer
can control it is by constantly bringing out new releases/bug fixes, then
you will get maybe a lot of buggy code released, so that at least you
have to quote your serial number before they will support you!

Not a good idea:-)

What I as a vendor like to see is time bombed evaluation code - You can give
it away, knowing that it won't last - and copy protected software that 
will restrict multiple copies on a single network to the licenced maximum.

That is until we get a government grant to sell and support software :-)

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 11:38:38 GMT
From:      leo@unipalm.uucp (E.J. Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: LM/X

martino@logitek.co.uk (Martin O'Nions) writes:
>We don't use the packet drivers regularly with LM, largely because we have
>the 3+ Open TCP software kicking around everywhere, but we did run PC/TCP
>with LM for test purposes. There is a Packet Driver to NDIS TSR which feeds
>the packet driver requests into the NDIS stack, and feeds the response
>back up the chain. We had problems with early versions of this when doing
>repeated loads/unloads of the driver, (it crashed the machine) but I believe
>that this has been addressed (comments anybody?)

It has Martin - long time no hear? Perhaps that 3COM TCP/IP is the reason!

leo

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 11:49:16 GMT
From:      leo@unipalm.uucp (E.J. Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: SVR4 and FTP's software

pjh@mccc.edu (Pete Holsberg) writes:

>It was suggested to me the other day that the POP servers available in
>the P.D. and the POP[23] mail software that FTP supplies with PC-TCP
>Plus may not work under the TCP/IP support provided with UNIX System V
>Release 4.x.  Could an experienced person please try to shed some light
>on this?
 
>Thanks,
>Pete
>-- 
>Prof. Peter J. Holsberg      Mercer County Community College
>Voice: 609-586-4800          Engineering Technology, Computers and Math
>UUCP:...!princeton!mccc!pjh  1200 Old Trenton Road, Trenton, NJ 08690
>Internet: pjh@mccc.edu	     Trenton Computer Festival -- 4/20-21/91

I have ported a POP2 server starting from P.D. code to INTEL system V.4
it is not too bad a port: there are still a few minor problems associated
with the mail system rather than the POP daemon itself. 

It is a LOT easier to port BSD/ULtrix code to V.4 thatn it is to V.3 tho.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 12:27:32 GMT
From:      jel@tuura.UUCP (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO <-> Sun == molasses

jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes:

>	I've set up a PC running SCO Unix 3.2.1.  It mostly runs fine, but
>FTP and NFS traffic between it and a SparcStation 1+ running SunOS 4.1.1 is
>um, pathetic.  FTP transfers of 0.5 K/s.  NFS reads that (almost) never
>complete.
>	I suspect the window size negotiation breaks down, since telnet
>works fine.  Anybody know any workarounds/bugfixes?
>--
I have had similar problems and there is a workaround. In my case the
problem was that the default SCO TCP window and NFS request size are
4 KB.  Unfortunately when the SparcStation behaves accordingly and
pumps out three or four Ethernet frames in rapid succession the poor
PC Ethernet adapter can not keep up and drops all but the first frame.

The workaround with TCP is to give the  -onepacket flag to ifconfig 
(see manual for details). With NFS you have to give mount options
which make the read and write sizes small enough so that the request
will fit into a single Ethernet frame.

An alternative is buying a better Ethernet adapter. I saw the problem
with Etherlink II but the Western Digital cards do quite a bit better.
At least our 486 machine with WD8013EBT seems to keep up quite well 
with our SPARCserver 330 without any parameter tweaking.

Jerry Lahti
Nokia Data Systems Oy
Domains: jel@xerver.data.nokia.fi

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 13:41:12 GMT
From:      abc@rock.concert.net (Alan Clegg)
To:        comp.protocols.tcp-ip
Subject:   slip-4.1-beta and sliplogin

I have recently installed the slip-4.1-beta code into the kernel of a
SparcStation 1+, and am trying to get the sliplogin code from the slip-4.0
release working.

There were a couple of places where I had to change SLIPIFNAME from slip to
stream, but other than that, I see nothing too different (I did change the
push of "slip" to "slipen" and added the push of "str_ip"). 

Now, when I use sliplogin, I get a kernel panic shortly thereafter from totally
unrelated processes (BAD TRAP).  If I use slip-attach (supplied in 4.1-beta),
everything stays up.

Has anyone successfully gotten sliplogin working under 4.1-beta?

Thanks,
-abc

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 14:10:16 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1108 and IP Security options?

Since nobody's answered this, I'll try.  Note that my information may be
out of date...

    RFC 1122 section 3.2.1.8(a) refers to an RFC 1108, "Internet Protocol
    Security Options," by one B. Schofield, dated October 1989.  RFC 1122
    also specifically warns that RFCs 1038 and 791 are obsolete, though it
    cites 791 as the source of its MUSTs and MAYs.

What this means is that nobody in the DoD wants the IP Security Option as
defined in either RFC 791 (the same as in Mil Std 1777) or RFC 1038
(major changes from the original RFC 791).  However, RFC 1038 is a *lot*
closer to the mark.  RFC 1108 was intended to replace 1038, with a bunch
of constants changed for the Blacker people, and the 'right' exception
handling procedure for both single-level hosts, multi-level hosts and
routers.  However, it seems to have fallen into some interdepartmental
black hole since 1989 (I believe the person doing it got moved, and I
don't think anyone inherited both the responsibility and the authority.

    What is the current authoritative reference in this area?

I don't know of one.  What we implement in our current production version
of PC/TCP is a mid-89 draft of what was intended to become RFC 1108.
Nobody in the DoD has complained about this, but that could simply
indicate that noone is using our IPSO - I know they have PC/TCP...

At the time I was in touch with people at Cray, but I don't know exactly
what they implemented, and the only other mention of IPSO that I've seen
recently was Wollongong (VMS and SysV).  Their glossy only mentions RFC
1038 and I don't have a copy to play with.  The matter has come up at at
least one IETF I attended, but no answer was at hand.  If you somehow
become enlightened, let us know...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 14:10:18 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: When is a link saturated?


    I have been trying to interest people in using the Precedence field
    where appropriate, as well as TOS.

Note that current production PC/TCP allows the setting of the Precedence
field on a per-PC basis (The API also allows it on a per-connection
basis, but none of our applications set it).  A separate configuration
item allows the user to enable Precedence checking as defined in the Mil
Std for TCP (1776?), so you can use it for either router traffic
identification, or to let a general override the ranks, as it was
originally designed to.  

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 16:25:56 GMT
From:      stu@jpusa1.chi.il.us (Stu Heiss)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   why is 386 tcp limmited to one slip session?

Someone posted that most 386 tcp implementations are limmited to
one slip.  This is true for the Lachman port on Xenix that we use.
Why is this and is there any way to support more than one slip?
-- 
Stu Heiss - stu@jpusa1.chi.il.us

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 16:50:00 GMT
From:      MGRJTC@ROSEVC.Rose-Hulman.EDU ("Jerrod T. Carter, Networking Manager")
To:        comp.protocols.tcp-ip
Subject:   Certified SMTP mail

We have recently installed a new NOVELL mail system called PMAIL. One of the
features allows you to request a confirmation once the mail message is
delivered. I think this is an EXCELLENT idea. I had previously thought of this
before, so when I saw it I was happy.

This is accomplished by putting a line in the headers that only PMAIL
recognizes. Now to the point. What would other people think of making some sort
of standard header line that other mailers can act on? It's not hard to
understand, and is easy to implement. So, let's hear what you think. If people
choose to reply to me, I will count the votes and summarize to the net and take
appropriate action. Thank.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jerrod t. carter, networking manager     |    my employer has no opinions
rose-hulman institute of technology      |
MGRJTC@RoseVC.Rose-Hulman.Edu            |    "may all your faults be soft."
MGRJTC@RHIT.BITNET                       |

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 16:52:14 GMT
From:      theall@rm105serve.sas.upenn.edu (George A. Theall)
To:        comp.protocols.tcp-ip
Subject:   Re: Loooking for lpd for DOS w/packet drivers

In article <91038.121146KOEHLER@awiwuw11.wu-wien.ac.at> KOEHLER@awiwuw11.wu-wien.ac.at (Wolfi) writes:
>Has anyone seen a public domain version of the UNIX lpd program as an
>implementation on a DOS PC which works together with packet drivers and/or PC/T
>CP from FTP Software ?

   An implementation written by Dave Johnson (dave@cs.olemiss.edu) is
available, I believe, in beta release. It works with the Clarkson
packet driver collection but is *not* public domain. At present I don't
have a machine name from where it can be obtained via FTP but if you
contact me I'll dig around for it.

   There is also an lpd server available from ogre.cica.indiana.edu
(129.79.22.178) as part of tn3270iu.zip in directory ~/pub. I have
not examined this; it is probably not public domain either.

    Also, I hear FTP Software markets an LPD server for DOS. While you
do say "public domain", consider the value of support which comes with
commercial products.
    
George
--- 
theall@rm105serve.sas.upenn.edu			Dept. of Economics
theall@ssctemp.sas.upenn.edu			Univ. of Pennsylvania
gtheall@penndrls.upenn.edu			Philadelphia, PA 19104

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 18:05:00 GMT
From:      imp@Solbourne.COM (Warner Losh)
To:        comp.protocols.tcp-ip,comp.mail.uucp
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?

Will@cup.portal.com (Will E Estes) writes:
>Can someone briefly discuss any standards that might exist, or be
>in the process of development, for the sending of secure mail via
>SMTP or via the Internet.  Also, are there any relevant RFCs on
>this topic?

There are a couple of RFC's (1113, 1114, 1115) on something called
"Privacy enhancment for Internet electronic mail", which is mail that
has been encrypted.  There are some provisions for authenticating the
sending user, but they are "weak".

While there is an account called "root" with all the privs that it
has, there will be no way to have "totally secure, authenticated
mail".  After all, if I wanted to send mail from Joe Hothead to his
boss calling him a jerk, then I could su, then su jhothed and flame
away.  And it could be done w/o a way to trace it back it me (after
all, root can nuke accounting files).

User authentication is a difficult problem to solve completely.  Also,
while there are sites on the Internet with older mailers (and can't be
upgraded to the latest sendmail since they aren't running Unix), there
will be a problem with mailer spoofing.  Even with the latest
sendmail, I could send mail to Joe's boss as Joe w/o any privs.

Or, in other words, you can't trust your mail 100%, since it is
relatively easy to forge.

However, I encourage all reasonable steps that can be taken to
authenticate a connection.  There are many hueristics that can be used
to detect clumsy forgeries.

Warner
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 18:41:18 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

>Basically, the only difference you should see between an Ethernet Internet
>connection and a SLIP Internet connection is the speed and throughput.

Well, I might not go *that* far.  Ethernet has a checksum, and SLIP
doesn't, so if you're, say, using UDP without checksums, Ethernet may be
more reliable than SLIP....

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 18:50:44 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip,comp.mail.uucp
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?

In article <1991Feb8.180500.11290@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes:
>While there is an account called "root" with all the privs that it
>has, there will be no way to have "totally secure, authenticated
>mail".  After all, if I wanted to send mail from Joe Hothead to his
>boss calling him a jerk, then I could su, then su jhothed and flame
>away.  And it could be done w/o a way to trace it back it me (after
>all, root can nuke accounting files).

 Forget about root.  Sure root can violate privacy.  But what does that
matter when anybody with a terminal server can telnet to the SMTP
port of any host, and start entering an SMTP mail transaction.  In this
case even the 'Received:' headers won't be of much help in narrowing down
the source of the message.

 If you want 100 percent secure communication, talk face to face with the
person intended.  Actually, even that is not 100% foolproof, or else there
would be little point in having agencies such as the CIA.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 18:58:40 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   using DNS and YP/NIS together

I have a few questions regarding using DNS and NIS/YP concurrently:

When must host names be fully qualified in files,  (/etc/netgroup,
/etc/exports, etc.) in order for the two to work together?

I was informed that if any hosts were built into the YP maps, that the lookup
would consult YP, not DNS, for those hosts.  Are there any other dire
consequences than this?  

Are there any other caveats to be heeded?

Any help will be much appreciated.


Charles DeRykus				Internet:   ced@bcstec.boeing.com
Boeing Computer Services		UUCP:	    ...!uunet!bcstec!ced
Renton, WA.  M/S 6R-37			(206) 234-9223

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 19:27:49 GMT
From:      randall@Virginia.EDU (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: have you compiled NCSA Telnet w/Turbo C?

In article <1991Feb07.214707.16739@ecst.csuchico.edu>, 
	madams@ecst.csuchico.edu (Michael E. Adams) writes:

>I won't waste your time detailing the aggravation I
>experienced sorting out the tel23src.zip rats nest of files
>from NCSA.
>
>Still, I would love to hear from anyone who has successfully
>compiled the Telnet programs with Turbo C.

For several months late last spring and summer, I was working with
the NCSA Telnet 2.3 Beta sources under TC/TC++.  The folks at NCSA
should have changed some of the sources by now based on my comments
back then and a fairly recent 2.3 Beta shouldn't require too much
effort to compile with TC.

Back then, the main problems were that the sources were laden with
non-ANSI header files that are unique to MS C.  In many cases, the
header <stdlib.h> should replace one or more MS C headers.  Also,
there were some incorrectly placed #defines that kept TC from seeing
headers that it needed to see and caused it to see headers that it
shouldn't see.  I think that most of the actual C source will be fine,
but the headers and #defines will take some tweaking.  You might
also want to turn off the "no prototype" warning since the order of
declaration of the functions in some of the files causes them to
be defined after all other references to them.

I think that if/when the NCSA folks switch to a newer compiler than
MS C 5.1, it will be easier for them to make NCSA more ANSI conforming
and hence TC/TC++ compatible.  (This might already have happened.)

I'm not actively working on the NCSA sources at the moment due to
other projects, but I think that all would benefit if problems with
getting the NCSA Telnet sources to compile with mainstream (Borland,
Watcom, Microsoft, Zortech, etc.) compilers were reported with suitable
fixes.  I've been impressed with the quality of response from the NCSA
folks to technical problems and questions.

I've posted rather than replied because I think that this might be
of more general interest.  

Ran Atkinson
randall@Virginia.EDU

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 20:37:03 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>Well, I might not go *that* far.  Ethernet has a checksum, and SLIP
>doesn't, so if you're, say, using UDP without checksums, Ethernet may be
>more reliable than SLIP....

Surely nobody would be so stupid as to use UDP without checksums. :-) :-)

(For those who don't get the point of the ":-) :-)", NFS uses UDP without
checksums.  And people wonder why NFS is so unreliable...)
-- 
"Maybe we should tell the truth?"      | Henry Spencer at U of Toronto Zoology
"Surely we aren't that desperate yet." |  henry@zoo.toronto.edu   utzoo!henry

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 21:51:41 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>Well, I might not go *that* far.  Ethernet has a checksum, and SLIP
>doesn't, so if you're, say, using UDP without checksums, Ethernet may be
>more reliable than SLIP....

On the other hand, if you're running NFS (the only common use I know of
for UDP without checksums) over SLIP, you may have worse problems :).

Of course, I'm firmly in the end-to-end-reliability-check camp, and thus
I think that running UDP without checksums is just a way of asking for
trouble.  I still fail to understand why it was done in NFS.  Sigh.

-- 
Amanda Walker						      amanda@visix.com
Visix Software Inc.					...!uunet!visix!amanda
--
If you know what you're doing, how long it will take, or how much it will
cost, it isn't research.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 22:35:39 GMT
From:      imp@Solbourne.COM (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

In article <C13C5DEE293FE00507@ROSEVC.Rose-Hulman.Edu>
MGRJTC@ROSEVC.Rose-Hulman.EDU ("Jerrod T. Carter, Networking Manager")
writes: 
>This is accomplished by putting a line in the headers that only PMAIL
>recognizes. Now to the point. What would other people think of making some sort
>of standard header line that other mailers can act on?

There is a header called Return-Receipt: that various sendmail
versions seem to grok.  Maybe that is the way to go....

Note that delivering the mail doesn't actually mean that the person
will read the mail.  Every month or two around here a couple of people
loose mail because of a disk crash w/no backup since the incoming mail
was sent.  I don't know what PMAIL does, but unless return receipt is
integrated into the mail reading program, it too would suffer from
this problem.

Also, I didn't think NOVELL used TCP/IP at all.  Don't they use IPX?

Warner
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 22:50:14 GMT
From:      raj@pollux.geog.ucsb.edu (Richard A Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Promiscuous Mode - RS/6000 Ethernet Adapter

If you look at /usr/include/net/if.h on the RS/6000 you find a note that
promiscuous mode doesn't work currently.  I'm trying to find out from IBM if
they will EVER get it.  No answer yet.

(Text from /usr/include/net/if.h:)
/* next two not supported now, but reserved: */
#define IFF_PROMISC     0x100           /* receive all packets */
#define IFF_ALLMULTI    0x200           /* receive all multicast packets */

-----------------------------------------------------------------------------
Richard A. Johnson                           raj@topdog.ucsb.edu   (Internet)
NCGIA Computing Resources Manager                  ucbvax!ucivax!raj   (UUCP)
U. C. Santa Barbara                      raj@ncgia.ucsb.edu (via Nameservers)

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 23:31:01 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <1991Feb8.203703.25654@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes:
> 
> (For those who don't get the point of the ":-) :-)", NFS uses UDP without
> checksums.  And people wonder why NFS is so unreliable...)


Everyone!  Please stop repeating this complaint.  It doesn't take much
perception or knowledge to find many real and inconvenient differences
between NFS and other UNIX file systems. If complaining about NFS brings
you joy, then complain about open-unlink, caching, security, ownership &
UID's, dates, and idempotency holes.  If you don't like using NFS, then use
something else like AFS or "the emerging standard, RFS" (AT&T press
release, 1986).

Anyone with an NFS implementation that does not use UDP checksums should
either fix or enjoy it.  The NFS on common and current workstations does
use UDP checksums by default.  Ours do.  I'm told that Sun's does as
of the NFS 3.2 source release.

I personally think the choice made in 1984 (85?) was correct for 1982
thru 1988.  The fact that for years (!) NFS has used UDP with checksums
turned on makes our disagreement about the correctness of the original
decision almost as interesting today as the old arguments whether "HLL's
will replace assembly language".


Vernon Schryver,  vjs@sgi.com

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 Feb 91 23:49:47 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1108 and IP Security options?

The problem of RFC-1108 has been receiving a great deal of back-room
attention recently, and people who should know keep telling me
"next month".

Bob Braden

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 01:59:43 GMT
From:      vcerf@NRI.RESTON.VA.US
To:        comp.protocols.tcp-ip
Subject:   RFC1108/IP Security Option Status

Folks,

just to update you on this matter, there is urgent effort underway (since last
November) to put the final touches on RFC1108. It did fall into a black hole
for most of the last half of 1990 owing to various personnel shifting but
has been resurrected and is being debated by key parties. With any luck we
should have the final go around in late February and can report it out to
IESG/IAB at that time. 

The focus of RFC1108 is quite US specific and there is strong need to 
consider a broader framework for document markings for the bulk of the
Internet community. To that end, effort is under way to develop a
"commercial" option which would tackle the non-military case (indications
are that a sufficiently general formulation might work for military and
non-military cases, but this remains to be seen).

The topic will probably surface at the next IETF meeting, in any event,
so stay tuned.

Steve Crocker has the IETF action. Steve Kent has been working the RFC1108
problem with the assistance of an ad hoc group of government representatives
whose needs RFC1108 has to satisfy.

Vint Cerf

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 02:28:31 GMT
From:      vcerf@NRI.RESTON.VA.US
To:        comp.protocols.tcp-ip
Subject:   SLIP for NeXT

Does NeXT have SLIP or PPP support? 

Please respond to vcerf@nri.reston.va.us to avoid bothering
the list.

thanks,

Vint Cerf

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 02:50:36 GMT
From:      cscc12@jetson.uh.edu
To:        comp.protocols.tcp-ip
Subject:   Seek help on how to load PC NCSA & driver(s) to Ext. or Exp. Memory


	Hello everybody,
	   Can any of you please show me how to load PC NCSA Telnet and its 
driver(s) into extended or expanded memory if this is possible. Thanks in 
advance.

Loc Thanh Le
cscc12@menudo.uh.edu
cscc12@elroy.uh.edu

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 04:27:15 GMT
From:      peiffer@umn-cs.cs.umn.edu (Tim Peiffer (the net guy))
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
   Well, I might not go *that* far.  Ethernet has a checksum, and SLIP
   doesn't, so if you're, say, using UDP without checksums, Ethernet may be
   more reliable than SLIP....

This sounds like you are willing to compare apples to oranges.  IP
differs not at all whether it originates on a coaxial Ethernet, or a
slow speed serial line.  UDP without checksums is only mentioning that
you are willing to disallow checksums at the transport level.  This
option exists under both Ethernet and SLIP connections.  The network 
level (IP) still has a checksum that resides at byte 12.  I believe
that V. Jacobsen (RFC 1144) states that the COMPRESSED_IP checksum
will be accomplished at byte 5.  RFC1055 refers one back to the
IP document for the content of the IP header.

Tim Peiffer
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
MPLS MN 55455


** Internet Protocol
  A summary of the contents of the internet header follows:
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   |         Identification        |Flags|      Fragment Offset    |
   |  Time to Live |    Protocol   |         Header Checksum       |
   |                       Source Address                          |
   |                    Destination Address                        |
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 04:28:42 GMT
From:      dyim@athena.mit.edu (Derrick H. Yim)
To:        comp.protocols.tcp-ip
Subject:   Socket Library for MacTCP

I am looking for a UNIX Socket library for the Macintosh implemented using
MacTCP. I would like to write a program which would allow me to exchange
data between a Macintosh and a UNIX box using stream sockets. I'm working in
MPW C, so libraries written for MPW would be preferred. Can anyone help me out?

Please send e-mail, since I'm not a regular netnews reader.


Derrick Yim

dyim@athena.mit.edu 
dyim@media-lab.mit.edu

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 05:16:23 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <84702@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>> (For those who don't get the point of the ":-) :-)", NFS uses UDP without
>> checksums.  And people wonder why NFS is so unreliable...)
>Everyone!  Please stop repeating this complaint.  

I agree that the complaint is wrong, but not for the same reason you do.
It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in
general (in its default configuration).  In fact, SunOS doesn't provide a
way for a UDP-based application protocol to control whether it uses
checksums -- it's a single, system-wide parameter.  Even worse, this one
parameter controls both whether checksums are generated during sending and
whether they are checked when receiving.

>Anyone with an NFS implementation that does not use UDP checksums should
>either fix or enjoy it.  The NFS on common and current workstations does
>use UDP checksums by default.  

I think Suns would count as "common and current workstations", and by
default SunOS doesn't enable UDP checksums.  In fact, until SunOS 4.1.1,
enabling UDP checksums required patching the kernel; in the latest release
they've finally moved it into a configuration file used during the kernel
build process.

>				Ours do.  I'm told that Sun's does as
>of the NFS 3.2 source release.

Since the socket library doesn't provide a way to enable or disable UDP
checksums (I could be wrong -- I simply searched for "checksum" in the
setsockopt man page), I don't see how the NFS source release can do this.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 14:35:48 GMT
From:      jdeitch@jadpc.cts.com (Jim Deitch)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: why is 386 tcp limmited to one slip session?

In article <1991Feb8.162556.6584@jpusa1.chi.il.us> stu@jpusa1.UUCP (Stu Heiss,925,6326,none) writes:
>Someone posted that most 386 tcp implementations are limmited to
>one slip.  This is true for the Lachman port on Xenix that we use.
>Why is this and is there any way to support more than one slip?
>-- 
>Stu Heiss - stu@jpusa1.chi.il.us

You know what is really interesting, I just got done doing some work
on a Altos 1000, it is a 386 box that is using a modified SCO Unix,
running Lachman tcp.  They can support more than 1 concurrent slip.  I
wonder if the altos tcp can be laid down into sco unix and work?

Jim
-- 
ARPANET:    jadpc!jdeitch@nosc.mil
INTERNET:   jdeitch@jadpc.cts.com
UUCP:	    nosc!jadpc!jdeitch

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 19:04:00 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp

In article <1991Feb6.184300@sicsun.epfl.ch> goud@sicsun.epfl.ch (Mireille Goud) writes:
>        - If the 2 hosts are on the same network (same B class
>address) the size of the packets is negociated between the 2 hosts.
>        - If the 2 hosts are not on the same network (they don't have
>the same class address) the size of the packets is 512 bytes.
>1. Is this a ftp problem or a tcp problem ?

It's a problem/feature of many TCP implementations.  The reason it is done
is that the goal is to prevent fragmentation of datagrams.  Hosts on the
same network can agree to base the max segment size (MSS) on the maximum
packet size (called the MTU -- Max Transmission Unit) of the network.  If
they are on different networks, though, they don't know what the smallest
MTU is of all the intervening networks, except that all networks in a
TCP/IP internet are required to support at least 512-byte packets
(actually, I think the number is something like 568, to allow 512-byte TCP
segments plus IP and TCP headers).

>2. Is there a solution to have big packets (4K bytes on fddi) even if
>the 2 hosts are not on the same network ?

There is work going on to develop "path MTU discovery" mechanisms.  Also,
some TCP implementations use a larger MSS for subnet that are part of the
same subnetted network than for outside networks (on the assumption that
local area media are faster than wide area media, so the consequences of
greater retransmission due to loss of a fragment are less severe).
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 19:52:58 GMT
From:      protocom@terre (protocom-Laurent turcotte)
To:        comp.protocols.tcp-ip
Subject:   SLIP (Performance/reliablity)

I'm considering using (SLIP) via FTP to transfer files from a Macintosh to Sun
Sparc station. I know 4.3BSD unix implements SLIP.

I would be using TCP/Connect II 1.0 from Intercon Systems Corporation on the
Macintosh side.

The Sun would call the Macintosh via modem (SLIP) and establish an FTP session.

	(1) is SLIP reliable enough over noisy modem lines? (I know that the TCP and IP layers contains checksum block validations) or should I use something
 like ZMODEM or KERMIT.

	(2) is the question of speed which would be faster (SLIP/FTP, XMODEM or KERMIT)

	(3) which is the most flexible? I think SLIP since you can almost do anything with IP but send me your opinions.

Thanks (any feedback can help...)

Larry Turcotte
-- 
Larry Turcotte                           Internet:protocom@dmi.usherb.ca
computer science student/consultant
consulting company:Protocom              Is there anybody out there.....

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 20:11:02 GMT
From:      jliv@GIBBS.SFSU.EDU (John Loiacono)
To:        comp.protocols.tcp-ip
Subject:   HP's TCP/IP under MPE

I would like to hear from those of you who have set up MPE
hosts to interact with other MPE hosts and/or PCs running
HP's virtual terminal software, accross TCP/IP routers.

I have been told that this is difficult or impossible, at
best.  I hope to dispute this comment, and solve some
problems.  

Things to keep in mind...

1.	I am not experienced with MPE.
2.	I am experienced with TCP/IP, but not HP's under MPE.
3.	The routers support HP-Probe, and ARP.
4.	Hosts are HP 3000s and PCs are mixed variety.
5.	PCs talk with local hosts just fine.
6.	Remote hosts are accross 56Kb links.
7.	All local traffic is on Ethernet.

Please respond directly to me at jliv@gibbs.sfsu.edu, and I will
summarize upon request.

jliv

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 Feb 91 23:34:11 GMT
From:      jis@MIT.EDU (Jeffrey I. Schiller)
To:        comp.protocols.tcp-ip
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?


   Date: 8 Feb 91 18:05:00 GMT
   From: stan!imp@uunet.uu.net  (Warner Losh)
   Organization: Solbourne Computer, Inc., Longmont, CO
   References: <38975@cup.portal.com>, <1991Feb8.110317.3949@unipalm.uucp>
   Sender: tcp-ip-relay@nic.ddn.mil

   Will@cup.portal.com (Will E Estes) writes:
   >Can someone briefly discuss any standards that might exist, or be
   >in the process of development, for the sending of secure mail via
   >SMTP or via the Internet.  Also, are there any relevant RFCs on
   >this topic?

   There are a couple of RFC's (1113, 1114, 1115) on something called
   "Privacy enhancment for Internet electronic mail", which is mail that
   has been encrypted.  There are some provisions for authenticating the
   sending user, but they are "weak".

Actually the provisions for authenticating the sending user are quite
strong.  Each sender must have a "Certificate" to send privacy enhanced
mail. A Certificate is a signed (via public key technology) piece of
information that binds the senders name (as an X.500 distinguished name,
separate from any concept of "login" name) and their public key. There
will be at least three ways of obtaining a Certificate. The direct (and
most expensive) way will be to get one issued directly from RSADSI (the
company that is managing the authentication hierarchy) for $25.00. This
method will also require that you submit a notarized statement of your
identity (ie. a Notary Public will have to notarize a piece of paper
that you send to RSADSI, testifying that the notary was shown sufficient
evidence that you are who you claim to be).  The cheaper mechanism (and
more efficient one because no paperwork is required) will involve
someone in your company acting as an "Organizational Notary" (ON). ONs
will vouch for people in the company. However ONs will be under contract
to only issue Certificates legitimately.

   While there is an account called "root" with all the privs that it
   has, there will be no way to have "totally secure, authenticated
   mail".  After all, if I wanted to send mail from Joe Hothead to his
   boss calling him a jerk, then I could su, then su jhothed and flame
   away.  And it could be done w/o a way to trace it back it me (after
   all, root can nuke accounting files).

Not quite as easy as that. To send mail as me, will require knowledge of
my private encryption key (the "secret" key that corresponds to the
public key embedded in my Certificate). In my implementation of Privacy
Enhanced Mail, the secret key is stored not only in a file readable only
to me, but is also encrypted by a password that only I know.

"root" (or others) can still steal my private key, however to do so will
require either stealing my keyboard input when I am sending private
mail, or otherwise installing a trojan horse in the Privacy Enhanced
Mail software to steal my key. Although both of these steps are doable
by one who has sufficient privileges and/or skill, it is a *lot* harder
then merely "su" and then "su jhothed".

   User authentication is a difficult problem to solve completely.  Also,
   while there are sites on the Internet with older mailers (and can't be
   upgraded to the latest sendmail since they aren't running Unix), there
   will be a problem with mailer spoofing.  Even with the latest
   sendmail, I could send mail to Joe's boss as Joe w/o any privs.

Privacy Enhanced Mail is not a function of the mail transport system, it
is a step you take prior to sending mail or after having received the
mail. My implementation is in fact done as an editing step. First you
format your message in an editor, then you transform it to the
"enhanced" form and only then do you mail the message. In fact I have a
version which is implemented as a UNIX filter. You can pipe the
unenhanced message in, and get the enhanced message out.

   Or, in other words, you can't trust your mail 100%, since it is
   relatively easy to forge.

The goal of privacy enhanced mail is to allow you to trust your mail
closer to 100% then to 0%. The whole point is to make it hard to forge.

   However, I encourage all reasonable steps that can be taken to
   authenticate a connection.  There are many hueristics that can be used
   to detect clumsy forgeries.

The problem with using heuristics is that they often will flag a
legitimate message as a forgery! My strategy is to not trust any
information provided by the IP layer, as all of it can be forged. The
mechanisms in Privacy Enhanced Mail are designed to be trusted, and were
designed by people who know their business.

			-Jeff

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 91 00:13:51 GMT
From:      brian@ganglion.Canada.Sun.Com (Brian Onn)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents


Tim Peiffer (the net guy) <peiffer@umn-cs.cs.umn.edu> writes:
|> In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
|>    Well, I might not go *that* far.  Ethernet has a checksum, and SLIP
|>    doesn't, so if you're, say, using UDP without checksums, Ethernet may be
|>    more reliable than SLIP....
|> 
|> This sounds like you are willing to compare apples to oranges.  IP
|> differs not at all whether it originates on a coaxial Ethernet, or a
|> slow speed serial line.  UDP without checksums is only mentioning that
|> you are willing to disallow checksums at the transport level.  This
|> option exists under both Ethernet and SLIP connections.  The network 
|> level (IP) still has a checksum that resides at byte 12.  I believe
|> that V. Jacobsen (RFC 1144) states that the COMPRESSED_IP checksum
|> will be accomplished at byte 5.  RFC1055 refers one back to the
|> IP document for the content of the IP header.

*sigh* .  The net guy should read the RFC he mentions.  The IP checksum
is only for the IP header, and does not include the *data*.  IP relies
on the upper layer protocols (UDP, TCP) to provide checksumming of the
data.


What Guy is saying is that running UDP without checksums is more
reliable on an Ethernet due to the fact that the Ethernet frame
includes a checksum (CRC, actually) for all of the frame.  A SLIP frame
does not include a frame checksum, and this will allow bad data to be
passed up the protocol stack.  If the SLIP layer doesn't catch bad data
(ie, a bad SLIP frame), and the IP layer also doesn't checksum the
data, and higher up the UDP layer doesn't checksum the data, you've
just received bad data.


Brian.
-- 
_____________________________________________________________________
Brian Onn.                  Inet  : Brian.Onn@Canada.Sun.Com
Sun Microsystems of Canada. Uucp  : uunet!sun!suncan!brian
Product Support Specialist. Voice : (416) 477-6745.
---------------------------------------------------------------------

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 91 14:15:53 GMT
From:      HANK@VM.BIU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   SNMP comparison

I am in need of a product comparison between various SNMP management
products.  I am aware of the following products:

Product name            Company Name
------------            ------------
ACS4800 NMS             ACC
Dual Manager            Netlabs
Netmon III              SNMP Research
LAN Systems 9100 NMC    Hughes
LANCE/NMS               Micro Technology
OverVIEW                Proteon
NCC                     Unisys
NetCentral              cisco
SNMP Tools              FTP Software
SNMP                    Nysernet
SunNet Manager          Sun
Watchtower              Intercon Systems
WIN/MGT                 Wollongong
XNETMON III             SNMP Research

I have heard that Datapro has recently conducted a comparison - does
anyone know where I can buy that study?  Any other comparisons available?

My personal checklist includes the following points (leaving off the more
common ones):

- able to run on a b/w X-terminal
- able to connect via 5-6 X-windows sessions to the SNMP management system
  so that more than one person can manage the network
- able to click on a network icon and telnet over immediately to that box
- able to generate statistical reports based on IP port divisions

These requirements are in addition to the standard SNMP features one would
expect from an SNMP package.

Thanks,
Hank

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 91 15:07:57 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip,comp.mail.uucp
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?

Apologies for the advertisement, but it seems appropriate to point out
that I just posted a public-domain RFC 931 implementation under BSD to
alt.sources, along with patches to sendmail (5.65, 5.61, et al.) that
let you use $F in sendmail.cf for the remote user as per RFC 931. I
recommend that you add ``, auth $F'' to one of the Received: lines,
preferably the second, as a semi-standard format.

Sure, RFC 931 isn't a panacea. But it does turn mail into a secure
protocol, provided that TCP is made secure. Any university sysadmin
knows that 99% of all sendmail forgers don't have any resources other
than a telnet connection. Now we can close that hole for good.

authd 3.01 has been reported to work under SunOS 4.0 on a Sun 2/170,
SunOS 4.0.3 on a Sun 4/280, SunOS 4.1 on Sun 3/80, 3/160, 3/180, 4/60,
and 4/330, Ultrix 4.0 on a DECsystem-5820, Ultrix 4.1 on DECsystem-5820,
DECstation-5400, and VAX 8650, BSD 4.3 on some VAX, and Convex UNIX 8.0
on a Convex C210. It does peek in a few kernel data structures, but it
seems perfectly portable so far.

---Dan

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 91 20:02:49 GMT
From:      john.lorenc@canrem.uucp (john lorenc)
To:        comp.protocols.tcp-ip
Subject:   copy protection

To: ericd@sco.COM

ED>Some of the information, regarding TCP/IP from SCO, in this post is incorrect.
ED>I do not want to use network bandwidth to explain the issues, however I
ED>would be more than willing to Email concerned individuals directly about the
ED>the copy protection scheme and how it affects system adminstration and users.


I am cursious to see your explanation.  I do find it a nuisance to use those
"activation keys"

john.lorenc@canrem.uucp

John Lorenc
---
 ~ DeLuxe}ab #1061 ~ Live Long and Prosper..
--
Canada Remote Systems.  Toronto, Ontario
NorthAmeriNet Host

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 91 20:22:42 GMT
From:      jis@MIT.EDU (Jeffrey I. Schiller)
To:        comp.protocols.tcp-ip
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?


   Date: 10 Feb 91 15:07:57 GMT
   From: kramden.acf.nyu.edu!brnstnd@nyu.edu  (Dan Bernstein)
   Organization: IR
   References: <1991Feb8.110317.3949@unipalm.uucp>, <1991Feb8.180500.11290@Solbourne.COM>, <1991Feb8.185044.22132@mp.cs.niu.edu>
   Sender: tcp-ip-relay@nic.ddn.mil

   ...

   Sure, RFC 931 isn't a panacea. But it does turn mail into a secure
   protocol, provided that TCP is made secure. Any university sysadmin
   knows that 99% of all sendmail forgers don't have any resources other
   than a telnet connection. Now we can close that hole for good.

I wouldn't go so far as to say it makes mail a "secure" protocol. Though
it does help. However for it to be really useful, all the mail relays
between sender and receiver need to implement it. This is not only
unlikely, but is also beyond the control of the individual sender and
receiver. Furthermore even if all the hosts on the Internet adopted it
tomorrow, you still need to trust the administrations of all the way
points your mail is relayed through. This doesn't lend itself well to
anything but the weakest definition of the term "authentication."

The Privacy Enhanced Mail RFCs (sorry to sound like a salesman myself
here!) define an end-to-end mechanism exactly so that sender and
recipient need have no trust in the intermediate mail relays (and no
requirements on the software that they run). This permits me for example
to route an encrypted, signed mail message to you via Iraq and the
Soviet Union and when you receive it (if you receive it, but that is a
different problem :-) ) know that only you can decrypt its contents and
also know that only I could have originated the message.

			-Jeff

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Feb 91 20:50:47 GMT
From:      joe@oilean.uucp (Joe McGuckin)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail


I think it's a great idea. But why stop there? Why not have an additional confirmation 
that informs you when the message was actually read...


-- 
Joe McGuckin             oilean!joe@sgi.com
Island Software          joe@parcplace.com
(415) 969-5453

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 00:32:20 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

>It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in
>general (in its default configuration).  In fact, SunOS doesn't provide a
>way for a UDP-based application protocol to control whether it uses
>checksums -- it's a single, system-wide parameter.  Even worse, this one
>parameter controls both whether checksums are generated during sending and
>whether they are checked when receiving.

The latter two statements are true of BSD, as it comes from Berkeley,
from 4.3BSD to 4.3-reno.  Whether UDP checksumming is enabled or not in
BSD as it comes from Berkeley is, by default, under the control of the
COMPAT_42 #define; that doesn't seem to be on in most of the
configuration files, so I don't think the first statement is true of
BSD, although it is true of SunOS (SunOS != BSD).

>>				Ours do.  I'm told that Sun's does as
>>of the NFS 3.2 source release.
>
>Since the socket library doesn't provide a way to enable or disable UDP
>checksums (I could be wrong -- I simply searched for "checksum" in the
>setsockopt man page), I don't see how the NFS source release can do this.

It can if the default configuration of the NFS source release turns the
system-wide parameter on; he didn't say the NFS 3.2 source release lets
you arbitrary control whether UDP checksumming is done, he just said
that he was told that it *DID* UDP checksumming as of the NFS 3.2 source
release.

The NFS 4.0 source release is derived from 4.3BSD, and behaves like
4.3BSD in this regard - "udpcksum" is turned on only if COMPAT_42 is
defined, and it's not defined in the GENERIC configuration file. 

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 00:42:02 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

>This sounds like you are willing to compare apples to oranges.  IP
>differs not at all whether it originates on a coaxial Ethernet, or a
>slow speed serial line.

Yes, I know IP doesn't differ, but how reliably the link level checks
the link-level packets in which IP packets are wrapped *DOES* differ -
Ethernet has a checksum, and SLIP doesn't, as I said.

>UDP without checksums is only mentioning that you are willing to disallow
>checksums at the transport level.  This option exists under both Ethernet
>and SLIP connections.

If you disable UDP checksumming, the transmission of your UDP datagrams
will be checked by checksum when the transmission goes over Ethernet,
but not when it goes over SLIP, so if the transmission includes a SLIP
connection, that connection won't have any checksumming other than the
IP checksum you mention, which does *NOT* checksum the entire packet,
just the IP header. If the transmission includes only Ethernet
connections, it will be checksummed on each one of those hops.  (It
won't necessarily be checksummed as it's moved internally to any of the
intermediate machines, of course....)

>The network level (IP) still has a checksum that resides at byte 12.

Which only checksums IP headers; it doesn't check the entire datagram.

>I believe that V. Jacobsen (RFC 1144) states that the COMPRESSED_IP checksum
>will be accomplished at byte 5.

He also states that:

   This compression is specific to TCP/IP datagrams./2/  The author
   investigated compressing UDP/IP datagrams but found that they were too
   infrequent to be worth the bother and either there was insufficient
   datagram-to-datagram coherence for good compression (e.g., name server
   queries) or the higher level protocol headers overwhelmed the cost of
   the UDP/IP header (e.g., Sun's RPC/NFS).

so it's irrelevant to the discussion of UDP anyway.

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 02:33:35 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Why Fewer Buffers (was Changing TCP port)


>In a different string, it was asked why cisco might suggest using
>fewer buffers on slower links...

There is probably a more fundamental reason for cisco's statement
about using fewer buffers on slow-links:

Keeping response time (RTT/SRT/etc) small.

If you give a TCP the space, it will use it in an effort to maximize
thruput - perhaps not 'consciously' ;-) but by always sending as many
packets at a time as it can/is 'allowed.' While this is desirable for
your file transfers, it might very well make the telnet/vt users a
triffle peeved ;-)

Of course, in this case, 'truth' is a relative thing. For example, if
you 'know' that you never get a burst of traffic through your router
greater that N packets, you might want to configure that many buffers
so as to avoid retransmissions. However, that value of N is not only
difficult to determine, it is also unlikely to remain static. 

As congestion controlled TCP's are becomming all the rage ;-),
configuring fewer buffers is probably a good thing - the TCP's will
still try to use 'all' the bandwidth/buffers, but you won't allow them
to build-up such an enormous delay. File transfers go through, and
interactive goes through.

Of course, tuning the relative bandwidths given each is a further, related
matter - perhaps some info on how OS schedulers go about sharing a CPU
amongst processes would be enlightening ;-) Then we could think of all
those bits in the IP header(s) as specifying 'process priorities' on a
pkt/pkt basis...

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | HP-UX   Networking   Performance
| \_/   \_/    Hewlett-Packard  Co.   | "It's so fast, that _______" ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 08:42:04 GMT
From:      enag@ifi.uio.no (Erik Naggum, the Internet Purist)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

In article <1991Feb10.205047.2217@oilean.uucp>, Joe McGuckin writes:
> I think it's a great idea.  But why stop there?  Why not have an
> additional confirmation that informs you when the message was
> actually read...

I think (yet another) reality check on this topic is needed.  It can
be exemplified by the question:

	How often do you send registered mail?

If that is every time you send a letter, I sympathize with your need
to do the same with e-mail.  If not, I claim that you're going to do
it every time if it were possible, for a large number of "you".

The second, corollary problem is that even for a limited number of
users who request receipts on any of the events "message received",
"message read", "message understood", "mission completed", etc, on all
messages sent, the volume of mail will likely escalate exponentially.
Also, see below for a related volume problem.

The third problem is the Three Armies problem, where two allies A and
B are separated by an Enemy controlled area.  A can communicate with B
only _through_ the Enemy controlled area.

Say A plans to do a two-flank attack on E, and this requires the
cooperation of B, since a one-flank attack is close to suicide.  A
sends B a message: "Will attack from W at 0430.  Pls ACK."  The
following occurs:

	(1) B doesn't get the message (ordonance caught, shot, drown...)
	(2) B gets the message, and ACKs, but needs an ACK.

	    (1) A doesn't get the ACK.
	    (2) A gets the ACK, ACKs, but needs an ACK.

		(1) B doesn't get the ACKed ACK.
		(2) B gets the ACKed ACK, ACKS, needs ACK.

		    ...

As should be obvious, a lack of ACK is not a NAK.  An ACK is not
guaranteed to be delivered, and thus must be ACKed, ad infinitum.
Also, in the absence of an ACK, should A retransmit until an ACK is
received?  Should each party retransmit ACKs until properly ACKed?
What is the terminating condition of this recursion?

Consider what options exist in the absence of a "secure" ACK.  Either
party may not get the message or the ACK, but believe that the other
party has got it, for any iteration of the above process.  This may be
suicide, and may not be a viable option.

What would you do?  Or rephrased: If you don't get an ACK "message
received, read, understood, mission completed", which of the four
possible NAK conditions is true, or did the ACK fail to get delivered?

The corollary to this third problem is that the network will become
saturated with ACKed ACKs, or retransmitted messages.  The latter will
also occur if the recipient is not equipped to reply, or chooses not
to for any number of reasons.

So, the summary of this rather elaborate exposition of this one
problem of basic network technology, is:

	You don't want that.

--
[Erik Naggum]					     <enag@ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik@naggum.uu.no>

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 14:19:00 GMT
From:      TANNERC@CRL.AECL.CA (CHRISTOPHER TANNER)
To:        comp.protocols.tcp-ip
Subject:   Problem with WIN/TCP's secure FTP

Hi all
We are running WIN/TCP vs 5.1 on VMS 5.4 and are using the secure vs of
FTP as recommended by Wollongong. One problem that we have seen is that when
I am FTP'ing from VMS to another machine, the 'ls' command is actually sent
as 'ls<space><space>'  (ls followed by 2 blanks). This causes unknown
directory errors on NOS/VE, IRIS (r3.3), but not on SUN, Ultrix or PC/TCP
from FTP. (The command 'ls directory' works properly).

Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE
being too fussy?

Thanks in advance for your help.


Chris Tanner                                 TANNERC@CRL.AECL.CA
AECL Research

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 15:20:57 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams)
To:        comp.protocols.tcp-ip
Subject:   "certified" mail

Re: SMTP offering "certification" capabilities:

Count me as one vote representing many users that would like to see
SMTP include a "return receipt requested" feature that would send a
notice to the originator when the addressee reads the registered
message.

Mark L. Williams
Head, Telecommunications Branch
Code 7630
Naval Coastal Systems Center
Panama City, FL 32407-5000
(mark@telesys.ncsc.navy.mil)

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 15:42:47 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

Erik Naggum, Naggum Software, Oslo, Norway, offered a thoughtful rebuttal
to the idea of certified/registered mailers.  However, I believe that his
arguments overlook several issues:

1) Many organizations do use registered mail, or some other feedback
   mechanism, to verify that deliveries have been made.  The absence 
   of comparable mechanisms in SMTP is perceived as a shortcoming that
   must be tolerated, at best.

2) Many non-SMTP mail systems, especially those running on PCs and LANs,
   offer registered mail capabilities, making the absence of those
   capabilities in SMTP more obvious and irritating than they might
   be otherwise.

3) The ACK/NAK problem can be as troublesome on LANs as it would be on
   the Internet.  The fact that LANs supporting registered mail schemes
   do not typically collapse due to ACK/NAK cascades indicates that the
   real world can cope with mail registration successfully.

4) E-mail is certainly not the only means of communications available to
   most Internet users.  The lack of a receipt notice usually prompts our
   users to call the intended recipient to alert him/her to the presence
   of the mail.  This feedback opportunity can assist network administrators
   in identifying the existence of network problems if, for instance, the
   mail was never received.

Registered mail is certainly no panacea for assuring effective communications.
It can, however, provide important information for users and is in appreciable
demand in some environments.

Mark 

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 16:48:55 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

In article <1991Feb10.205047.2217@oilean.uucp> joe@oilean.uucp (Joe McGuckin) writes:
>I think it's a great idea. But why stop there? Why not have an additional confirmation 
>that informs you when the message was actually read...

That would be a good trick.  Unless by "read" you mean "displayed on the
user's screen, whether he actually read it or not"...
-- 
"Read the OSI protocol specifications?  | Henry Spencer @ U of Toronto Zoology
I can't even *lift* them!"              |  henry@zoo.toronto.edu  utzoo!henry

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 17:47:36 GMT
From:      iv@sun.Eng.Sun.COM (Ian Vessey)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   IEEE P1003.12 Seeks Input on Sockets and XTI (TLI).

The POSIX process-to-process communications working group (P1003.12)
would like to solicit outside comment.

Between November 1990 and January 1991, we asked your opinions as to
whether this working group should

        a)      Develop a 3rd interface akin to sockets and XTI,
        b)      Standardize either Berkeley sockets or XTI,
        c)      Standardize both sockets and XTI.

The results of the poll indicated that

        a)      The working group should not adopt a new third
                interface
        b)      The working group should adopt both sockets and XTI.

These poll results were endorsed by the committee and we are currently
pursuing a plan that provides a single language independent standard
which has two `C' bindings, one for sockets and one for XTI. These
two bindings will constitute our DNI(Detailed Network Interface). We
are also working on an SNI(Simple Network Interface) which views the
network from a far simpler standpoint and operates over the DNI.

The purpose of this mail is to not only feed back the results of the
poll and it's impact on our work, but to ask for further input.
Specifically, we would like comments on perceived problems with either
of the interfaces together with suggestions for additional features
that you believe would be useful to add to one or both of them.

Please keep in mind that backwards compatibility is very important
in any change requests proposed.

As before, please submit your comments to dot12@okeeffe.Berkeley.EDU.
It would be helpful if you could indicate on which news group you
read this article.

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 17:57:28 GMT
From:      roes@phcoms.seri.philips.nl (Aloys Roes)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   LAN-service TCP/IP

A few weeks a go I posted a request for an update for various versions
of TCP/IP. I got several replies for the CMU TCP/IP problem but none for
the LAN-service. Either noone is running that software or people are too
embarrassed to admit that they do. Anyway, we are facing the problem that
since VMS 5.3 the rsh is no longer working (crashes the system). 
Now that we want to upgrade to VMS 5.4 we will run into the problem with
the new password hashing algorithm that DEC introduced. 
We have been in touch with Novell who have taken over the Excelan
(LAN-service) hardware and software but they can only inform us that the
software will be in the public domain 'real soon now'. But there are some
legal problems to be solved first they claim. 
They suggest that a transition to Multinet is a preferred solution but
since we are phasing out our VMS systems we don't want to do any new
investments in VMS software. And since we have a service contract we feel
we have the right to request an updated version.

We would like to know if others are or have been in this situation as well.
If you have a solution or a good suggestion please contact us,

Thanks, 

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl
-- 
     regards,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 18:21:19 GMT
From:      imp@Solbourne.COM (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with WIN/TCP's secure FTP

In article <09F0D6D7E020051A@crl.aecl.ca> TANNERC@CRL.AECL.CA
(CHRISTOPHER TANNER) writes:
>I am FTP'ing from VMS to another machine, the 'ls' command is actually sent
>as 'ls<space><space>'  (ls followed by 2 blanks).

Are you sure?  I'm about 99% positive that it sends out an NLST
command when you type 'ls' to the prompt and a LIST command when you
type 'dir'.  I wouldn't doubt that it is putting an extra space at
the end, however.

>Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE
>being too fussy?

SGI and NOS/VE appear to be not conforming to the standard.  To quote
RFC 959, page 46:
	"The command codes and the argument fields are separated by
ONE OR MORE spaces."	(emphasis mine)

So, the path name doesn't begin until after the second space[*].  Since
there should be a <CR><LF> pair after the second space, this makes the
pathname argument NULL, so the implementation should list the current
directory.  This is due to the following in the description of
LIST(pp 32, ibid):

	"If the pathname specifies a directory [...] If the pathname
specifies a file [...].  A null argument implies the
user's current working or default directory."

and in NLST (p 33 ibid):

	"A null argument implies the current directory"

If it was me, I'd file this as an MR to TWG, none the less, since it
is causing interoperability problems.

Warner
--
[*] I guess a case could be made here that if there are to be no
arguments, then the command should be immediately followed by a
<CR><LF>.  However, other places call this argument a NULL argument,
rather than a missing argument.
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 18:50:26 GMT
From:      giamma@orc.olivetti.com
To:        comp.protocols.tcp-ip
Subject:   snmp agent MIB-II



Do you know if there are new free implementations of SNMP agent

that are MIB-II compatible ???? (like CMU, MIT and ISODE).

Thanks in advance,


giamma@orc.olivetti.com

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 19:24:19 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <1991Feb9.051623.29415@Think.COM>, barmar@think.com (Barry Margolin) writes:
> In article <84702@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >> (For those who don't get the point of the ":-) :-)", NFS uses UDP without
> >> checksums.  And people wonder why NFS is so unreliable...)
> >Everyone!  Please stop repeating this complaint.  
> 
> I agree that the complaint is wrong, but not for the same reason you do.
> It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in
> general (in its default configuration).  In fact, SunOS doesn't provide a
> way for a UDP-based application protocol to control whether it uses
> checksums -- it's a single, system-wide parameter.  Even worse, this one
> parameter controls both whether checksums are generated during sending and
> whether they are checked when receiving.

Isn't this the right way to do it?  With a "single, system-wide parameter"
controlling whether UDP is checksummed or not?  We argued among ourselves
years ago whether the NFS switch should be the same as the global UDP
switch.  Ultimately, we decided that those who want no UDP checksums on NFS
would not want them on anything else, including RPC, and conversely.  Some
might like a per-link switch, turning it on for SLIP lines and off for
Ethernet and FDDI.  (Having seen many checksums errors in FDDI frames with
good CRC and E-bit, I'm not one.)  Unfortunately, that idea does not work
with routers; you'd need a UDP-cksum-is-a-good-idea-discovery protocol.

The source from BSD has UDP checksums turned on by default.  I haven't
looked at the Reno NFS, but would be surprised if it's off there.

> >Anyone with an NFS implementation that does not use UDP checksums should
> >either fix or enjoy it.  The NFS on common and current workstations does
> >use UDP checksums by default.  
> 
> I think Suns would count as "common and current workstations", and by
> default SunOS doesn't enable UDP checksums.  In fact, until SunOS 4.1.1,
> enabling UDP checksums required patching the kernel; in the latest release
> they've finally moved it into a configuration file used during the kernel
> build process.

I finally used the source, and found I'm wrong about NFS3.2, which still
set the checksum=0.  In the NFS4.0 reference code, they follow the 4.3BSD
convention of obeying "udpcksum".  Poking around with `adb /vmunix` on a
vanilla Sun that says "SunOS Release 4.1-GFX-Rev.1 (GFXRev1)" finds the
horrifying fact that udp_cksum=0.  Thus, Sun appears to be disabling all
UDP checksums, not just NFS.  I hope someone from Sun will dispute this,
since I'd hate to have to tell everyone to sell their solar hardware and
buy flowers.***

> >				Ours do.  I'm told that Sun's does as
> >of the NFS 3.2 source release.
> 
> Since the socket library doesn't provide a way to enable or disable UDP
> checksums (I could be wrong -- I simply searched for "checksum" in the
> setsockopt man page), I don't see how the NFS source release can do this.

The NFS 3.2 source I meant was the kernel code received by NFS vendors who
pay maintenance or royalties to Sun.  It is in lib/libc/rpc/kdup_fastsend.c


Vernon Schryver,  vjs@sgi.com


*** Silicon Graphics has called our products "IRIS" for about as long as
  other machines have had solar labels.  That I feel compelled to append
  this says a lot about the validity of my claim about "common and current
  workstations."  Oh, well.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 19:26:29 GMT
From:      almquist@JESSICA.STANFORD.EDU ("Philip Almquist")
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp

Barry,
> It's a problem/feature of many TCP implementations.  The reason it is done
> is that the goal is to prevent fragmentation of datagrams.  Hosts on the
> same network can agree to base the max segment size (MSS) on the maximum
> packet size (called the MTU -- Max Transmission Unit) of the network.  If
> they are on different networks, though, they don't know what the smallest
> MTU is of all the intervening networks, 

correct so far, but

> except that all networks in a
> TCP/IP internet are required to support at least 512-byte packets
> (actually, I think the number is something like 568, to allow 512-byte TCP
> segments plus IP and TCP headers).

IP networks are required to support 68 octet packets without network
layer (IP) fragmentation (RFC 791 page 25).  The Internet folklore that
says that this number is 576 is erroneous.

Every IP host must be able to receive (and reassemble if necessary) 576
octet datagrams (RFC 791 page 25).  Thus, it is technically a protocol
error to send a datagram larger than 576 to any host unless the sending
host knows (perhaps because of a TCP maximum segment size negotiation or
an agreement between the system managers) that the receiving host can
accept larger datagrams.  Historically (and arguably still today) it has
been unwise to send larger datagrams to hosts on distant networks (even
when the remote host was prepared to receive larger datagrams), since
larger datagrams increase the likelihood that intermediate networks will
perform fragmentation, causing degraded performance.

It is recommended (but, surprisingly, not required) that a host be able
to receive (and reassemble if necessary) a datagram at least as large as
the MTU of its connected network (RFC 1122 page 56).  Because most hosts
follow this recommendation, it usually works to send MTU-sized datagrams
to other hosts on the same (sub)net.  However, as described above, there
are no guarantees.

The default TCP maximum segment size is 536 (not 512) octets, for the
reasons you gave (to allow 40 octets for IP and TCP headers - RFC 1122
page 85).

Finally, a minor nit: the standards talk about octets rather than bytes.
Octets are eight bit quantities.  Bytes are also eight bit quantities on
most most modern computers, but computer architecture is beyond the
scope of the TCP/IP standards.

							Philip

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 19:37:59 GMT
From:      rick@uunet.uu.net (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

> >I think it's a great idea. But why stop there? Why not have an additional confirmation 
> >that informs you when the message was actually read...
> 
> That would be a good trick.  Unless by "read" you mean "displayed on the
> user's screen, whether he actually read it or not"...


Even thats not good enough. A company I used to work for had an
office autmoation system that allowed you to give messages a "confirm on
read" status. So many people at the company applied it to everything
that I used to run a text editor directly on the mail box to "read" the
mail, then within the system, I "deleted unread" the messages. So, no
confirmation... (Just my way of playing with their minds I guess.)

Message confirmation is a great way to increase revenues if you charge
per message. Its a lousy way to run a mail system.  It basicaly replicates
the received ok handshakes from lower levels and is not necessarily
a useful indication. (I.e. what about all of the unacknowledged messages
I read?)

---rick

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 19:40:38 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp

In article <1991Feb9.190400.6078@Think.COM>, barmar@think.com (Barry Margolin) writes:
>                                                            ....     Also,
> some TCP implementations use a larger MSS for subnet that are part of the
> same subnetted network than for outside networks (on the assumption that
> local area media are faster than wide area media, so the consequences of
> greater retransmission due to loss of a fragment are less severe).

Some might fear worse consequences of IP fragementation in such an
environment, because the routers are likely to be general purpose systems
which just happen to have additional ethernet interfaces, and may not have
an abundance of buffering.

The justification I've heard most often for such switches is that the MTU
in the local internet is at least as large as the MTU on local ethernet,
1500 bytes.  In such a case, 1500 causes no more fragmentation than 576.  I
have seen large commerical, production networks where using 1500 instead of
the approved 576 improved FTP performance 3X.


The default configuration on an IRIS is "allsubnetsarelocal=true".
Do you guys consider this Evil, Wrong, and Grounds for Belittling Remarks?


Vernon Schryver,   Silicon Graphics,  vjs@sgi.com

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 20:54:02 GMT
From:      Ed Sale
To:        comp.protocols.tcp-ip
Subject:   TCP Urgent Pointer *Standard*

After reading the sections of the TCP and Host Requirements RFC's (included
below), it is still unclear to me how a standard TCP should set the
Urgent Pointer field of the TCP header in segments with the URG control
bit set.  My problems with the descriptions in the RFC's are:

	What does "positive offset" mean, precisely?
	What does "points to" mean, precisely?

My question boils down to this:

	If a TCP segment is carrying just one byte of data, and that
	one byte is urgent data, what value should the TCP header's
	Urgent Pointer field contain, 0 or 1? (In a *STANDARD* TCP.)

Also, in my experience with many TCP implementations, there is
apparently confusion about the value that the Urgent Pointer should
have, as they do not appear to all be setting this field the same way.
I guess even if I choose to implement *STANDARD* Urgent Pointer
processing I'm still not going to be able to converse effectively
with every TCP implementation out there :-(.

Thanks in advance for any insight you may provide into this problem.
My apologies if this question has been asked and answered here previously.
Please reply to me by mail, and I will post a summary of the responses I
get.

rfc793 (TCP), page 17,  lines 1204-10

"Urgent Pointer: 16 bits

 This field communicates the current value of the urgent pointer as a
 positive offset from the sequence number in this segment.  The
 urgent pointer points to the sequence number of the octet following
 the urgent data.  This field is only be (sic) interpreted in segments
 with the URG control bit set."


rfc793 (TCP), page 56,  lines 3523-4

"If the urgent flag is set, then SND.UP <- SND.NXT - 1 and set the
 urgent pointer in the outgoing segments"


rfc1122 (Host Requirements), page 84, lines 4917-22

"4.2.2.4  Urgent Pointer: RFC-793 Section 3.1

 The second sentence is in error: the urgent pointer points
 to the sequence number of the LAST octet (not LAST+1) in a
 sequence of urgent data.  The description on page 56 (last
 sentence) is correct."

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     Ed Sale  Intergraph Corp.  Huntsville, AL 35894-0001  (205)730-2000
			     b11!ed!sale@ingr.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 21:00:25 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with WIN/TCP's secure FTP

>We are running WIN/TCP vs 5.1 on VMS 5.4 and are using the secure vs of
>FTP as recommended by Wollongong. One problem that we have seen is that when
>I am FTP'ing from VMS to another machine, the 'ls' command is actually sent
>as 'ls<space><space>'  (ls followed by 2 blanks). This causes unknown
>directory errors on NOS/VE, IRIS (r3.3), but not on SUN, Ultrix or PC/TCP
>from FTP. (The command 'ls directory' works properly).
>
>Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE
>being too fussy?

According to my reading of the spec, it's Wollongong's problem.  The spec
clearly states that a keyword (NLST in this case) is followed either by
CR/LF if there are no parameters, or SP if there are parameters.  Also, the
syntax of the LIST and NLST commands is shown as having one optional
parameter:

   LIST [<SP> <pathname>] <CRLF>

"<pathname>" is defined as "<string>", which is defined as one or more
occurrences of <char>, which is defined as any ASCII char from 0 to 127
excluding CR and LF, but including space.  This implies that "LIST <SP>
<SP> <CRLF>" is a request to list a file or directory with a single
blank as its name.

Now, the semantics of recognizing a pathname require the treatment of a
null path as being "the current directory", but nothing prevents or
requires a server to strip white space from the pathname before any
further interpretation.

Doug Nelson
Michigan State University

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 21:09:47 GMT
From:      mmorse@NSF.GOV (Michael Morse)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail


> We have recently installed a new NOVELL mail system called PMAIL. One of the
> features allows you to request a confirmation once the mail message is
> delivered. I think this is an EXCELLENT idea. I had previously thought of this
> before, so when I saw it I was happy.
 
> This is accomplished by putting a line in the headers that only PMAIL
> recognizes.Now to the point. What would other people think of making some sort
> of standard header line that other mailers can act on? It's not hard to
> understand, and is easy to implement. 

Despite the popularity of this feature in the commercial world, and in
commercial (proprietary) mail systems, it is surprisingly difficult to
implement in SMTP/Unix based mail systems.  Here are just some of the reasons:

 1. Most Unix mail systems do not really have the concept of "when the
    user *reads* the mail."  If you talk to people who want this feature
    it turns out that they're not really interested that some machine has
    accepted responsibility for the message, they want to know that the
    recipient "got it" which means, "has looked at it."  Unix mail systems
    tend to stick mail in a file and let the user get to it by whatever
    method they choose.

    If you're actually talking about accepting responsibility, then most
    Unix systems that run sendmail already do this (just add 
    "return-receipt-to: your_name" to the message header and send it to a 
    Unix box).  Again, this is *not* what most people mean by certified
    mail, but if it is what you mean, I suggest you just use the
    sendmail convention (and skip the rest of this message).

 2. In SMTP, the header of the message is really not much more than text.
    That makes it difficult to implement a "when read" receipt.  The reason
    is that you only want to send the receipt once.  That means you must
    modify the header after you read it once.   Technically this is
    difficult to do in a relatively robust fashion on current Unix mail
    systems.  One of the reasons is that a large number of messages are
    usually contained in a single file, meaning you have to completely
    re-write the file, keeping it locked the whole while.

 3. There is a problem with mailing lists.  If someone addresses mail to
    a mailing list (such as this one) and requests certified mail, do they
    want a receipt from the list maintainer, or from everyone that receives
    a copy of the message?  Depending on how you answer this question, many
    other problems result, since it's very difficult to determine when
    a message has reached its final destination.  If you don't choose
    final destination as the point  to generate the certified mail, then you
    must design a method of specifying where to generate the receipt.

 4. However, the real problem is social:  there are many people on the
    Internet that consider this concept an invasion of their privacy (I
    should send you the flames I received when I proposed it a couple
    of years ago.)  The reasoning is that "my mail is my mail" and you have
    no right to know when I read it, if I read it, and you certainly can't
    use CPU resources on my machine to send a receipt.  The existance of
    this large group of people means that given the technical limitations
    listed above, a lot of people will subvert the feature, making it *much*
    less useful to the senders.

    This attitude is not limited to the Internet, but it is rare in the
    commercial world, where everything is considered by many to be the 
    property of the company or organization.  However, my experience is
    that it is a common attitude in the U.K.  This attitude resulted in
    the bizarre implementation of All-In-One for DEC, in which a user
    could configure things so that all mail he sent asked for a return
    receipt, but could also configure his mailbox so that no return
    receipts were ever sent to incoming mail.  Allowing a user to "turn off"
    receipts makes the feature less useful to an organization since users
    never know why they didn't get a receipt.  Again, in the commercial world
    you can simply decree "It's illegal to turn off receipts".  You just can't
    decree that in the Internet.

   The bottom line is that this feature will be easy to implement in a 
closed, proprietary mail system, and almost impossible in SMTP.  I believe it
is a feature of X.400, so it'll be interesting to see how it is implemented
(or not implemented) in the Internet/Unix world.


--Mike

Michael Morse                           Internet: mmorse@note.nsf.gov
National Science Foundation               BITNET: mmorse@NSF
1800 G St. N.W.   Room 401             Telephone: (202) 357-7659
Washington, D.C.  20550                      FAX: (202) 357-7663

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 21:22:00 GMT
From:      barmar@THINK.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp


    Date: Mon, 11 Feb 91 11:26:29 -0800
    From: "Philip Almquist" <almquist@jessica.stanford.edu>

    IP networks are required to support 68 octet packets without network
    layer (IP) fragmentation (RFC 791 page 25).  The Internet folklore that
    says that this number is 576 is erroneous.

Thanks for the correction.  However, it's reasonably safe to assume that
most media have an MTU of at least 512.  I can't think of any that
don't, and I would be surprised if anyone invented a new medium with a
smaller MTU (the current direction is generally towards larger packet
sizes).

    Finally, a minor nit: the standards talk about octets rather than bytes.
    Octets are eight bit quantities.  Bytes are also eight bit quantities on
    most most modern computers, but computer architecture is beyond the
    scope of the TCP/IP standards.

I know that, and I debated using "octet" in my message.  I chose to use
terminology consistent with the question.  It's rarely necessary to make
this fine distinction outside standards documents (people on systems
with non-8-bit-bytes generally know how to translate to their own frame
of reference).

                                                barmar

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 22:34:30 GMT
From:      ash@uupc.omega (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   NS DP8390 ethernet chip

I seem to remember some months ago talk about problems (dropped packets?)
with the A and B versions of the DP8390 chip as fitted to the WD8003E.
I notice that the new boards have the DP8390C chip. Can someone remind
me what the problem was and whether it (and any others that may have
existed in the A and/or B versions) were fixed in the C revision.
Thanks
-- 

Andrew Hardie                                       ash@omega.uucp
London, England                                ukc!cctal!omega!ash

No is merely a negotiating position; yes is always final.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 23:31:02 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <84878@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1991Feb9.051623.29415@Think.COM>, barmar@think.com (Barry Margolin) writes:
>> Even worse, this one
>> parameter controls both whether checksums are generated during sending and
>> whether they are checked when receiving.
>Isn't this the right way to do it?  With a "single, system-wide parameter"
>controlling whether UDP is checksummed or not?

From p.78 of RFC1122:

   An application MAY optionally be able to control whether a UDP checksum
   will be generated, but it MUST default to checksumming on.

   If a UDP datagram is received with a checksum that is non-zero and
   invalid, UDP MUST silently discard the datagram.

4.2BSD-based UDP implementations violate both these requirements.  First,
it is supposed to be the application that decides whether it wants
checksumming; in BSD, either all applications get it or none do.  Second,
it is not permitted to disable checking of received packets.

>  We argued among ourselves
>years ago whether the NFS switch should be the same as the global UDP
>switch.

I wasn't only complaining about the fact that it affects all applications.
I was complaining about the fact that you can't disable generation of
checksums but still enable checking of checksums.  Thus, even though my
client does checksumming correctly, errors will still get through if the
server has them disabled.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      11 Feb 91 23:52:06 GMT
From:      tom@mermaid.Litle.Com (Tom Hampton)
To:        comp.protocols.tcp-ip
Subject:   Anyone using Stratus TCP/IP with Wellfleet Router?

We are experiencing strange behavior between our Stratus computer and
our Wellfleet router.  The Stratus times out too fast (10 sec) and the 
Wellfleet seems bent on reporting "system not available."

Anyone else using this combo with success?
-- 
===============================================================================
 Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
                                               | +1 603 643 1832 
-------------------------------------------------------------------------------
 Design is figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@mermaid.litle.com                            {backbone}!dartvax!mermaid!tom
===============================================================================

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 00:07:51 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

There is a different kind of mail system where return receipts are
perfectly natural. All messages are very short, but can be accompanied
by one or more files that aren't sent at first but are held on the
sender's system. The recipient of the message can retrieve the
files---possibly compressed, encrypted, checksummed, whatever---with a
command or two. (When the initial message isn't required, this turns
into a BITNET-style file transfer system.) The sender is told when the
files are picked up, so he can use them as a (voluntary) return-receipt
system.

---Dan

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 00:29:53 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?

In article <9102102022.AA26112@osiris.MIT.EDU> jis@MIT.EDU (Jeffrey I. Schiller) writes:
  [ RFC 931 ]
> I wouldn't go so far as to say it makes mail a "secure" protocol.

But it does---again, provided that TCP is made secure.

The problem until now is that mail introduced its own security holes
over and above those of TCP: it didn't even try to verify the remote
username. Now at least we can reduce the problem to TCP.

> However for it to be really useful, all the mail relays
> between sender and receiver need to implement it.

I'm not convinced that this is such a problem. The Internet mail I send
rarely goes through more than three hops: nyu.edu, bar.com, foo.bar.com.
If sending organization and receiving organization support RFC 931,
that's enough.

> The Privacy Enhanced Mail RFCs (sorry to sound like a salesman myself
> here!) define an end-to-end mechanism exactly so that sender and
> recipient need have no trust in the intermediate mail relays (and no
> requirements on the software that they run).

I have no objection to end-to-end security (although I don't like the
current fashion of putting it into every single protocol instead of
making the link level secure). But we don't have the software yet. I
also hope that if NYU decides to spend any money on RSA Inc., it starts
by putting a few thousand dollars into challenging the RSA patent.

Furthermore, mail encryption doesn't do anything for news, telnet,
rlogin, talk, or any of the other services people use. RFC 931 helps all
of them the same way it helps mail.

---Dan

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 02:05:49 GMT
From:      almquist@JESSICA.STANFORD.EDU ("Philip Almquist")
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp

Barry,
> However, it's reasonably safe to assume that
> most media have an MTU of at least 512.  I can't think of any that
> don't, and I would be surprised if anyone invented a new medium with a
> smaller MTU (the current direction is generally towards larger packet
> sizes).

	SATNET had an MTU of somewhere around 250, if I recall
correctly, but I'm pretty sure it's now defunct.  I also seem to recall
that Van uses a similar MTU over his compressed SLIP dialup line (since
he doesn't preempt an FTP data packet that is being transmitted when a
Telnet packet is queued for transmission, he wants to ensure that the
FTP data packet is short enough that its transmission can be completed
without noticeably delaying the transmission of the Telnet packet).  I
don't know what sorts of MTUs are used for packet radio, but they may be
pretty small for similar reasons.

	ATM networks will also use very small packets, but I guess the
expectation is that they will do Link Layer fragmentation to present the
appearance of a reasonably large MTU to the Network Layer.  In general,
I agree that the trend is for new kinds of networks to have much larger
MTUs.

>> Finally, a minor nit: the standards talk about octets rather than bytes.
 
> I know that, and I debated using "octet" in my message.  I chose to use
> terminology consistent with the question.  It's rarely necessary to make
> this fine distinction outside standards documents...

	Like I said, it was a minor nit, and I almost omitted it.  You
should probably chalk it up to fond memories of the days when I worked
on computers which have a far more flexible concept of what a "byte" is.

							Philip

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 03:21:30 GMT
From:      lee@gdc.portal.com (Seng-Poh Lee, Speedy)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Source/binaries for talk/d, rwho/d, finger/d for HP-UX

Hello,

I am looking for binaries (or source that will compile on HP-UX 5.5) for
the following BSD network utilities;

talk and talkd
rwho and rwhod
finger and fingerd

I am currently running inetd with ftp, telnet, and rlogin (which came with
the system)  but I would like those other utilities. If anyone has them
running, please let me know. I have access to ftp or can receive them in
uuencoded compressed/tar format by mail

Thanks in advance

Seng-Poh Lee		lee@gdc.portal.com

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 04:25:01 GMT
From:      brown@wucs1.wustl.edu (Mike Brown)
To:        comp.protocols.tcp-ip
Subject:   SNMP "manageability" ?!?

I recently learned that a major U.S. router vendor defines SNMP management
as the ability to "monitor" their equipment via SNMP and not the
configuration of the equipment via SNMP.  I believe that I understand
the security problems related to SNMP and why caution must be exercised
with the use of SNMP to configure network elements.  I still believe that
SNMP can be an effective configuration mechanism in certain networks.


My question is:  Does any router vendor support configuration via SNMP?

If you think I am naive for using SNMP to configure network elements then
please let me know...

	Regards,
	Mike Brown	Corporate Telecommunications
			Information Systems
			One Bell Center, Rm 24-V-5
			Southwestern Bell Telephone Co.
			St. Louis, MO  63101
			(314) 235-7863

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 06:14:08 GMT
From:      ericd@sco.COM (Eric Davis)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: why is 386 tcp limmited to one slip session?


In article <1991Feb09.143548.11116@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes:
>They (altos) can support more than 1 concurrent slip.  I
>wonder if the altos tcp can be laid down into sco unix and work?

SCO TCP/IP for Unix can have more than one SLIP connection. As for
Xenix TCP/IP, not sure. I can check an post when I find out.

Ericd

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Eric Davis                      () INTERNET -=> ericd@sco.COM
Technical Support Engineer II   () UUCP     -=> {uunet|sun|att|ucsc}!sco!ericd
The Santa Cruz Operation Inc.   ()
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 08:07:29 GMT
From:      pedrotti@nrm6.UUCP (PEDROTTI)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Looking for PD source for ftp,tftp,telnet.

If anyone has information how to get public domain
sources for ftp, tftp and telnet (client AND server),
please send mail.
Thanks a lot in advance!

Philippe Pedrotti @ SIEMENS Corp., Munich, Germany.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 09:10:28 GMT
From:      joe@oilean.uucp (Joe McGuckin)
To:        comp.protocols.tcp-ip
Subject:   Ethernet based serial port expanders?

Has anyone ever seen such a gadget? I know there are terminal servers, but they usually
lack full control of the serial port. I'm looking for something that looks (software-wise)
and acts just like a serial port on a Sun and hooks up via ethernet.

-joe


-- 
Joe McGuckin             oilean!joe@sgi.com
Island Software          joe@parcplace.com
(415) 969-5453

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 13:47:12 GMT
From:      vcerf@NRI.RESTON.VA.US
To:        comp.protocols.tcp-ip
Subject:   SLIP and PPP for NeXt

Thanks to all who have taken time to respond. I enclose
the summary for anyone else who is interested.

Vint Cerf
----------


------- Forwarded Messages

Date: Sat,  9 Feb 91 21:19:02 -0500 (EST)
From: "Douglas F. DeJulio" <dd26+@andrew.cmu.edu>
To: vcerf@NRI.Reston.VA.US
Subject: Re: SLIP for NeXT

The company NeXT doesn't support it, but individuals have ported "dial
up ip" to the NeXT.  I've got it installed and will be shortly setting
it up to replace my Sun2 as our house's SLIP router, if I can.
- -- 
Doug DeJulio
dd26+@andrew.cmu.edu (ATK/AMS)
ddj@zardoz.club.cc.cmu.edu (NeXT)


------- Message 2

To: vcerf@NRI.Reston.VA.US
Subject: Re: SLIP for NeXT 
Date: Sat, 09 Feb 91 11:22:16 PST
From: Van Jacobson <van@ee.lbl.gov>

Vint,

I don't know if they're distributing their versions but I've heard
of two NeXT cslip ports, one by Louie Mamakos (louie@sayshell.umd.edu)
and one by Morris Meyer (Morris_Meyer@NeXT.COM).

 - Van

------- Message 3

Date: Sat, 9 Feb 91 22:17:36 EST
From: Pat Barron <pat@orac.pgh.pa.us>
To: vcerf@NRI.Reston.VA.US
Subject: Re: SLIP for NeXT
Newsgroups: comp.protocols.tcp-ip
Organization: Pat's Sun-2/120

In article <9102082128.aa16873@NRI.NRI.Reston.VA.US> you write:
>Does NeXT have SLIP or PPP support? 

There is a dial-up SLIP package available for the NeXT.  It can be FTP'ed from
next.com (or some machine in that domain - I'm not sure, since I don't use
it myself).  As I remember, it was either written or ported by Cal Thixton
at the NeXT Pittsburgh sales office.  You might try calling him for more
details (I don't have the number handy, but you can get it from Directory
Assistance in area code 412).

- --Pat.

------- Message 4

Date:     Sat, 9 Feb 91 9:53:06 MST
From: Jacob Gore <jacob@blackbox.gore.com>
To: vcerf@NRI.Reston.VA.US
Subject:  Re: SLIP for NeXT
Newsgroups:  comp.protocols.tcp-ip

/ comp.protocols.tcp-ip / vcerf@NRI.RESTON.VA.US / Feb  8, 1991 /
> Does NeXT have SLIP or PPP support? 

Not yet.

Jacob
- --
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob

------- Message 5

Date: Sat, 9 Feb 91 14:26:14 EST
From: bob@morningstar.com
To: vcerf@NRI.Reston.VA.US
Subject: SLIP for NeXT
Cc: Jamey Laskey <jamey@morningstar.com>

We have a PPP product under development for the NeXT, among others,
and due out Real Soon Now.  We're reluctantly considering adding
optional SLIP support - how important is that to you?  Contact Jamey
Laskey of Morning Star Technologies at +1 800 558 7827 or +1 614 451
1883.

------- Message 6

Date: Mon, 11 Feb 91 23:22:58 PST
From: "Eric P. Scott" <eps@sutro.sfsu.edu>
To: vcerf@NRI.Reston.VA.US
Subject: Re: SLIP for NeXT

>Does NeXT have SLIP or PPP support?

Not officially, but [129.18.18.3]:pub/Slip/* suggests that
this may change.
					-=EPS=-

------- Message 7

Date: Mon, 11 Feb 91 13:23:38 -0500
From: Rick Adams <rick@uunet.uu.net>
To: vcerf@NRI.Reston.VA.US
Subject: Re: SLIP for NeXT

I put some of the NeXT engineers in touch with the Telebit engineers
who are doing the NetBlazer. NeXT was very interested and in fact got
an early beta test NetBlazer.


- --rick

------- Message 8

Date: Mon, 11 Feb 91 07:43:18 MST
From: "Mitchel W. Sukalski" <mws@juggler.lanl.gov>
To: vcerf@NRI.Reston.VA.US
Subject: Re:  SLIP for NeXT

Vint-

I've asked that same question on comp.sys.next and of our NeXT gurus here.
No, there is no SLIP or PPP support for 2.0; moreover, there is no System
V STREAMS support to port more conventional implementations.  One of our
folks here, though, has been told by some folks at NeXT that they are working
on a PPP implementation.

Mitch Sukalski
LANL

------- Message 9

To: vcerf@NRI.Reston.VA.US
Cc: mts@terminator.cc.umich.edu
Subject: Re: SLIP for NeXT 
Date: Sun, 10 Feb 91 19:27:38 -0500
From: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>


I'm asking the same question right now.  If you get any answers about PPP
please let me know.

I can already answer the question about slip.  Someone from NeXT ought to
answer directly, but who knows what they read.  The slip changes are kern-loader
loadable; they can be integrated without making direct kernel modifications.
If you get no answer from next, I'll send you the names (mail addresses) of
people you can bug.

... you can have what I've got (slip).

mts.
michael t. stolarchuk
U of Michigan
Ann Arbor, Mi. 48105


------- End of Forwarded Messages

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 14:19:32 GMT
From:      mckee@chance.mitre.org (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   PSE info request

Last Spring or Summer there was a note to the list about a book:
ASN.1 The Tutorial and Reference.  The book was available from 
a firm named PSE.  I've lost the address and phone number; I would
appreciate a pointer to either.  Thanks - Craig

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 15:09:54 GMT
From:      jackson@bdrc.bd.com (Gene Jackson)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for MAC

We are interested in finding a good tcp-ip system for Macintosh computers
using ethernet.  We would like for the Macs to be NFS clients using a SUN
as an NFS server.  We also need mail running on the Macs that can send and 
receive from SMTP.  Thanks for any suggestions.  We are particularly interested
in hearing from users who have successful systems running.

					Gene Jackson
					jackson@bdrc.bd.com

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 15:39:59 GMT
From:      cpw@SNOW-WHITE.LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp

Vernon,

>The default configuration on an IRIS is "allsubnetsarelocal=true".
>Do you guys consider this Evil, Wrong, and Grounds for Belittling Remarks?

No, but some subnets are more equal than others. :^)

Phil

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 15:43:35 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   SunOS UDP checksums

In SunOS 4.1.1, udp_cksum is still off.  The only progress towards any
sort of intelligence on Sun's part is that they finally *document* it,
and even cover how to set it by editing one C file when building a
kernel.  And it finally does affect NFS!  (It never did in SunOS 3.X!)

We've recently had serious NFS file corruption problems because of the
absolute impossibility of enabling NFS/UDP checksums on SunOS 3.5.2,
which we still use on a key development machine.  (It was due to a bug
in a development router corrupting packets.)  At least when I upgrade
it (someday) to SunOS 4.1.1, I'll get checksums.

Presumably, Sun chooses to ignore RFC 1122 (Requirements for Internet
Hosts -- Communication Layers).  It is dated October 1989, so I
seriously doubt that SunOS 4.1.1 had a feature freeze that long ago.
(However, we have heard that the path from the TCP/IP group at Sun to
SunOS is very long, and fraught with delays, so it may well be that
the fix has been in the pipeline for a year.  If that is the case,
kudos to the TCP/IP group, and would the SunOS group get off their
tails!)  It would be nice to hope that SVR4 will conform to the host
requirements RFC's...

To re-quote the section of UDP checksums:

         4.1.3.4  UDP Checksums

            A host MUST implement the facility to generate and validate
            UDP checksums.  An application MAY optionally be able to
            control whether a UDP checksum will be generated, but it
            MUST default to checksumming on.

            If a UDP datagram is received with a checksum that is non-
            zero and invalid, UDP MUST silently discard the datagram.
            An application MAY optionally be able to control whether UDP
            datagrams without checksums should be discarded or passed to
            the application.

I have no idea if Sun would reply to a bid that required RFC 1122
conformance and claim conformance.  They don't conform.

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 17:10:48 GMT
From:      jcurran@SH.CS.NET (John Curran)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with WIN/TCP's secure FTP

--------
Hmm..  RFC959 is slightly contradictory regarding the spaces between the 
command and argument fields:

pg. 46
>            LIST [<SP> <pathname>] <CRLF>
>            NLST [<SP> <pathname>] <CRLF>
where <SP> is NVT-ASCII notation for space and hence does not allow 
multiple spaces.  <pathname> is defined to allow a leading space.

versus

pg. 45
> The command codes and the argument fields are separated by one or more
> spaces.

The host requirement application layer rfc (1123) has this on the subject:

>        4.1.4.1  Pathname Specification
>
>           Since FTP is intended for use in a heterogeneous
>           environment, User-FTP implementations MUST support remote
>           pathnames as arbitrary character strings, so that their form
>           and content are not limited by the conventions of the local
>           operating system.
>
>           DISCUSSION:
>                In particular, remote pathnames can be of arbitrary
>                length, and all the printing ASCII characters as well
>                as space (0x20) must be allowed.  RFC-959 allows a
>                pathname to contain any 7-bit ASCII character except CR
>                or LF.

Since the specification is inexact, I'd let each vendor (WG, CDC, and SGI) 
know about the interoperability issue, so that they all have the option of
"fixing" their s/w. Of course, as a side issue, the next round of clarifications
should be tightened to allow leading spaces in filenames (of questionable value) 
or multiple spaces as a delimiter. 

/John

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 17:26:31 GMT
From:      imp@Solbourne.COM (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with WIN/TCP's secure FTP

In article <9102120858.AA14961@ucbvax.Berkeley.EDU> Doug Nelson
<NELSON%MSU.EDU@CUNYVM.CUNY.EDU> writes:
>This implies that "LIST <SP>
><SP> <CRLF>" is a request to list a file or directory with a single
>blank as its name.

No, I must disagree with your reading of the RFC.  On page 46 of RFC
959 states:
	"The command codes and the argument fields are separated by
one or more spaces"

LIST<SP><SP><CR><LF> is a list command that has a NULL pathname
argument (since it starts after the last <SP> and ends before the
<CR>).

It is clear from reading RFC 1123 that the ftp daemon should be able
to accept any string that doesn't have a <CR> or a <LF> in it.
However, in light of the text I sighted above, it would appear that
the path name can't start with a space.  This would seem to indicate a
small hole in the FTP spec.

I just noticed that the SunOS 4.0.3 ftpd insists on having just one
space between the command and the arguments.  Checking the source
makes this reason rather obvious.  The reason that "LIST<SP><SP>"
works on the sun (and I guess other BSD machines) is that this turns
into a popen ("ls -lg  ") which will list the current directory.

However, like I said before, I'd file a bug with Wollongong since
it is an interoperability issue.

Warner
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 17:32:51 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <1991Feb11.233102.24222@Think.COM>, barmar@think.com (Barry Margolin) writes:
> 
> From p.78 of RFC1122:
> 
>    An application MAY optionally be able to control whether a UDP checksum
>    will be generated, but it MUST default to checksumming on.
> 
>    If a UDP datagram is received with a checksum that is non-zero and
>    invalid, UDP MUST silently discard the datagram.
> 
> 4.2BSD-based UDP implementations violate both these requirements.  First,
> it is supposed to be the application that decides whether it wants
> checksumming; in BSD, either all applications get it or none do.  Second,
> it is not permitted to disable checking of received packets.


The important word in the first paragraph is "MAY".  1122 does not require
that an application be able to disable UDP checksumming.  4.3BSD does not
have such a switch, and does not violate 1122 by not having it.

As long as you don't break it by changing udpcksum, 4.3BSD does not violate
the second paragraph.

The fact that 4.3BSD has additional characteristics cannot rationally be
considered a violation of the standard.  If the characteristic of being
able to change to non-conforming behavior is sufficient to be non-standard,
then only ROM based systems can be standard, since there are always
bozos--err--valued customers who can, will, and do change things in ways
you and I consider obviously stupid and non-conforming.  Does the fact that
many people installed their own implementations of TCP/IP (often BSD
derived) on popular workstations by itself make those systems non-1122
compliant even when running the vendor supplied system?  If the answer to
that question were yes, then 1122 and 1123 would be uninteresting to
workstation vendors and our customers.

Please keep standards carping rational.  It appears that some common
workstations (not my employer's) violate the above quoted part of 1122.
Their "feet should be held to the fire".  You are putting out the flame
when you lump 4.3BSD checksumming behavior with theirs.


(I'm assuming you mean 4.3BSD base UDP implementations, which follow the
rules you criticize, not 4.2 BSD.)


Vernon Schryver,   vjs@sgi.com

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 20:59:15 GMT
From:      oberman@rogue.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?READ/NEW/FOLLOWUP

In article <28229:Feb1200:29:5391@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> In article <9102102022.AA26112@osiris.MIT.EDU> jis@MIT.EDU (Jeffrey I. Schiller) writes:
>   [ RFC 931 ]
>> I wouldn't go so far as to say it makes mail a "secure" protocol.
> 
> But it does---again, provided that TCP is made secure.
> 
> I'm not convinced that this is such a problem. The Internet mail I send
> rarely goes through more than three hops: nyu.edu, bar.com, foo.bar.com.
> If sending organization and receiving organization support RFC 931,
> that's enough.
 
This is a rather parochial point of view. My site has over 1000 nodes which are
not on the Internet, They get thier mail through various gateways and the use
of 931 doesn't appear to do me a bit of good. And I'm hardly exclusive.

There's BITNET, Usenet, HEPnet, SPAN, ATTmail, Compuserve, MCImail, and a
nearly endless list of other mail systems which make 931 an impractical
solution to the problem.

I agree quite strongly that the only real way to do the job is with public key
end to end encryption or with digital signatures (as appropriate). I admit that
I'm still a bit unsure of how x.509 cetificates will be issued in "the real
world", but that gets into philosophy and is not germain.

I do think it's a bad idea to espouse a method because "it will be good enough
for me". A real solution should be good enough for everyone.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 21:14:09 GMT
From:      ehrlich@cs.psu.edu (Dan Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   Using a Hayes modem for SLIP?


(Please no flames.  My boss is making me do this.)

We need to run SLIP through a Hayes Smartmodem compatible from Packard-Bell.
Does anyone know if this is possible?  Does anyone have any suggestions for
what the modem settings should look like?  Is it even possible to do?  Yes
I realize it is painfully slow, but we are just trying for a proof of
concept and do not really care to much about the performance.

Thanks in advance.


--
Dan Ehrlich - Sr. Systems Programmer - Penn State Computer Science
<ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 21:20:42 GMT
From:      bzs@world.std.com (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail


Re: ack'd mail

The hard cases, as has been pointed out, are very hard indeed. The
easy cases, however, are quite easy.

If we assume that these receipts, read and other returns are voluntary
then they belong in the mail user interface. Perhaps the transport
agents would be aware of these to the extent that avoiding loops and
handling errors might be within its purview.

So, we add a field like:

	Mail-Options: Reply-When-Read

to request one and

	Mail-Options: Read-Reply

To mark one.

and the mail user agent is free to ignore it, send a reply, or even
ask the person what to do at that point. Systems which sell as
"secure" closed systems can assure that this will be handled in some
specified manner. Systems which don't, don't. If it's popular then it
probably will become fairly reliable, if not, then not.

We can standardize a field and string for doing this sort of thing and
just leave it to the implementors to decide how strictly to try to
implement it.

But, at least, we've provided one common way that the concept is
expressed (mechanism, not policy.) The worst case is every mail
subsystem builder deciding this is needed and doing it differently.

	-b
-- 
        -Barry Shein

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

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 21:52:28 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp

In article <9102111926.AA09697@jessica.stanford.edu> almquist@JESSICA.STANFORD.EDU ("Philip Almquist") writes:

   IP networks are required to support 68 octet packets without network
   layer (IP) fragmentation (RFC 791 page 25).  The Internet folklore that
   says that this number is 576 is erroneous.

   Every IP host must be able to receive (and reassemble if necessary)
   576 octet datagrams (RFC 791 page 25).  Historically (and arguably
   still today) it has been unwise to send larger datagrams to hosts
   on distant networks (even when the remote host was prepared to
   receive larger datagrams), since larger datagrams increase the
   likelihood that intermediate networks will perform fragmentation,
   causing degraded performance.

Or worse.  A few years ago a user at a certain unnamed milnet host
was unable to FTP to a PC under my purview running KA9Q.  I had set
the PC's MTU to 1024.  When I set the MTU down to 576, he had no
troubles.  Hopefully his software has been fixed by now, but I'll
take the hit in efficiency rather than spend time answering questions.

--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Feb 91 23:46:08 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   KEEPALIVE does not work

I attempted to modify a network daemon to enable `keepalive' on a TCP socket.
A code fragment is included below, with my addition inside an ifdef.  I removed
the error returns to shorten this article.  The code appears to work, but when
I watch the packets with etherfind on another machine, I can't see the
keepalive packets.  Should they be visible?  Did I miss something?  Does SunOS
4.1 not suport keepalive?  In case anyone wonders, the non-blocking i/o is
disabled later in the code, after a select().  The TCP read is always
interrupted by an alarm.  Could this interfere with keepalive?  I would like to
use keepalive so my daemon can detect when the remote host breaks its TCP
connection.  On an idle connection, my daemon spends most of its time in the
TCP read.


sc = socket(AF_INET, SOCK_STREAM, 0);
if (sc < 0) {
}
#ifdef UOFMCC
if (setsockopt(sc, SOL_SOCKET, SO_KEEPALIVE, (char *)(n=1, &n), sizeof(n)) < 0) {
}
#endif
if (ioctl(sc, FIONBIO, (char *)(n=1, &n)) < 0) {
}

if (connect(sc, (struct sockaddr *)&toaddr, sizeof(toaddr)) < 0) {
	if (errno != EINPROGRESS && errno != EWOULDBLOCK) {
	}
}
 
-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 01:08:32 GMT
From:      ariel@prime.com (Rob Ullmann)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

Hi,

there is already a de facto standard for "certified mail".

Include a header field Return-Receipt-To: <address>
(the exact syntax identical to Reply-To:)

You will get a delivery report from the mailer doing final delivery,
if it supports receipts.

If the user "reads" it with an interface that supports it, you will
get a "read receipt".

Rob Ullmann
Prime Computer, Inc.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 01:19:36 GMT
From:      mbh@copsw33.UUCP (Marc Hasson)
To:        comp.protocols.tcp-ip
Subject:   Tcp/Ip on Token-ring (VMEbus)


Does anyone know of a vendor which manufactures Token-ring cards for a
VMEbus machine?  So far I've confirmed (verbally only) that Interphase
and CMC both have intelligent Token-ring VMEbus cards but I'd really
prefer a "dumb" card, if possible.  A 6U form factor is a requirement.

ANY leads appreciated, intelligent or dumb. :-)
            
             
   --Marc Hasson


UUCP mail: suntzu!tdat!mbh@sun.com

U.S. mail: Teradata
           100 N. Sepulveda Blvd.
           El Segundo, Ca. 90245

Phones:    213-524-6062 (direct)
           213-524-5000 (main)

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 01:53:10 GMT
From:      mogul@wrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp

In article <19910211212243.8.BARMAR@OCCAM.THINK.COM> barmar@THINK.COM (Barry Margolin) writes:
>    From: "Philip Almquist" <almquist@jessica.stanford.edu>
>
>    IP networks are required to support 68 octet packets without network
>    layer (IP) fragmentation (RFC 791 page 25).  The Internet folklore that
>    says that this number is 576 is erroneous.
>
>Thanks for the correction.  However, it's reasonably safe to assume that
>most media have an MTU of at least 512.  I can't think of any that
>don't, and I would be surprised if anyone invented a new medium with a
>smaller MTU (the current direction is generally towards larger packet
>sizes).

RFC1191 ("Path MTU Discovery Protocol") lists all the MTUs I could
track down when I was writing it.  Several networks have MTU == 508,
and in RFC1144, Van Jacobson points out that on low-speed links
(like telephone lines) the use of too large an MTU may increase the
delays encountered to the point where they become unpleasant.  To quote:

   From the discussion in sec. 2, it seems desirable to limit the maximum
   packet size (MTU) on any line where there might be interactive traffic
   and multiple active connections (to maintain good interactive response
   between the different connections competing for the line).  The obvious
   question is `how much does this hurt throughput?'  It doesn't.

However, when Chris Kent invented the old "use 576 if non-local" rule,
he was attempting to avoid fragmentation-induced communication failure
without unduly reducing throughput.  576 is a compromise; it is essentially
an arbitrary number that was chosen because it seemed less arbitrary than
any other choice.  Until you can rely on PMTU Discovery, the 576-rule
works pretty well, but it does not guarantee non-fragmentation.

-Jeff

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 01:58:26 GMT
From:      tasman@CS.WISC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent Pointer *Standard*

Ed Sale writes:

> My question boils down to this:
>
>	If a TCP segment is carrying just one byte of data, and that
>	one byte is urgent data, what value should the TCP header's
>	Urgent Pointer field contain, 0 or 1? (In a *STANDARD* TCP.)
> 
> Also, in my experience with many TCP implementations, there is
> apparently confusion about the value that the Urgent Pointer should
> have, as they do not appear to all be setting this field the same way.
> I guess even if I choose to implement *STANDARD* Urgent Pointer
> processing I'm still not going to be able to converse effectively
> with every TCP implementation out there :-(.


     A brief answer to Ed's question is that the Urgent Pointer field should
contain 0.

     For a more detailed treatment of the philosophy and implementation of TCP
Urgent, you may wish to read an article that I wrote last summer:

	Tasman, M., "Telnet Output Discard Processing,"
	ConneXions: The Interoperability Report, Volume 4, No. 6, June 1990.

     A footnote to the article addresses the compatibility issue.  Due to
the specification confusion concerning TCP Urgent, some early implementations
contained an "off by one" calculation error.  Rather than alter the behavior
of their TCP implementation, at least one supplier chose instead to compensate
in the application programs.  The preceding will make more sense if you
read the article.

					Mitchell Tasman
					UW-Madison Computer Sciences Dept.

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 03:00:41 GMT
From:      spider@peano.zk3.dec.com (Spider Boardman OSG/CSSE)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: UCX and CDCnet problem

In article <k2.665828184@woodstock> k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:

>Our problem:
>If somebody trys to connect from a CDCnet node to our VAX, the connection
>sets up, but he get no prompt, until he/she types in a Break-character.
>With some debugging, we found out, that the VAX doesn't respond immediately
>with a login prompt, if the other side doesn't support the Terminal Type option
>(as in CDCnet!). The prompt appears after some input, like a local
>terminal. That dolt CDCnet isn't able to send a character at this stage,
>only BREAK got it to send something! So there are two problems,
>one side is UCX which barfs on a missing Terminal Type Option,
>and CDCnet which isn't able to send at this stage.

There is a patch available for this particular problem in UCX, which you should
be able to get from your Customer Support Center (CSC).  CDCnet I can't help
you with.
--
Spider Boardman					spider@decvax.dec.com
DEC OSG/CSSE					...!decvax!spider
I don't speak for DEC, and vice versa.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 06:07:06 GMT
From:      srodawa@vela.acs.oakland.edu (Ron Srodawa)
To:        comp.protocols.tcp-ip
Subject:   Re: have you compiled NCSA Telnet w/Turbo C?

Brad Clements at Clarkston University has modified NCSA Telnet et al to be
compilable both with Microsoft C and Borland Turbo C.  He can't
release the source to the current version right now, but I think there is
still old source on their archives.  As far as I know, NCSA never fit
these changes back into their version.  Ron.

-- 
| Ronald J. Srodawa               | Internet: srodawa@vela.secs.oakland.edu |
| School of Engineering and CS    | UUCP:     srodawa@vela.UUCP             |
| Oakland University              | Voice:    (313) 370-2247                |
| Rochester, Michigan  48309-4401 |                                         |

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 06:24:35 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP "manageability" ?!?

In article <1991Feb12.042501.6758@cec1.wustl.edu> brown@wucs1.wustl.edu (Mike Brown) writes:
>My question is:  Does any router vendor support configuration via SNMP?

cisco routers appear to, although I haven't actually tried it.  When you
enable SNMP you can specify read-only or read-write on a per-community
basis, and also specify an access list to restrict addresses from which
each community name is valid.

>If you think I am naive for using SNMP to configure network elements then
>please let me know...

It's still pretty early in the network management business, and many
vendors are just starting to provide SNMP facilities.  Some have jumped in
feet first, while others are still unsure how it fits in.  For instance, I
don't think any Unix systems are yet shipping with SNMP support (luckily
there are publically-available snmpd implementations, of various levels of
quality).

By the way, I've seen a couple of SNMP posts here recently.  There is a
mailing list snmp@nisc.psi.net on which SNMP is discussed; it includes both
users and implementors.  Send mail to snmp-request@nisc.psi.net to ask to
be added.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 06:37:59 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <85079@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>> 4.2BSD-based UDP implementations violate both these requirements.
>(I'm assuming you mean 4.3BSD base UDP implementations, which follow the
>rules you criticize, not 4.2 BSD.)

No, I meant 4.2BSD, since that is the release whose default value of
udpcksum is wrong.  Since the latest release of SunOS has this default
wrong, I assumed it is 4.2-based (but perhaps they changed the default in
the process of porting 4.3 TCP/IP, due to another of their misguided ideas
about backward-compatibility (the same misguidedness that causes them to
continue to default the broadcast address wrong)).  I'm not sure what the
latest Ultrix does, but I think 3.5 had the wrong default.  These are the
only BSD-based systems I have access to (we've got an SGI box, but it won't
let me login because it doesn't mount my home directory (I've never before
used a Unix system that didn't say something like "can't access home
directory, using /").
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 11:44:36 GMT
From:      koelman@issun3.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip for the Mac

Hello there,

Can anyone recommend a tcp/ip implementation for a Mac II?

Ton Koelman, SHAPE Technical Centre. The Hague (koelman@stc.nl)

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 15:15:47 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Are There Standards For Secure Mail Transfer Via SMTP?

In article <1991Feb12.135915.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes:
  [ RFC 931 doesn't help him, and it doesn't help on any non-TCP/IP net ]
> I do think it's a bad idea to espouse a method because "it will be good enough
> for me". A real solution should be good enough for everyone.

Dave Borman told me the same thing about RFC 1143. ``It isn't the only
way to stop TELNET's option negotiation loops,'' he said (paraphrased),
``and I don't like its approach. So it must not become a standard.''

There's one missing step. Why does a solution have to be perfect for
everyone? Why can't all solutions be published in parallel? People who
like one solution will use it. People who like another will use that.
I've never said that RFC 1143 is the *only* way to fix TELNET, and I'm
not saying now that RFC 931 is the *only* way to improve mail security.

RFC 931 would, however, prevent many---if not most---of the SMTP
forgeries that go on now. So it is worthwhile for many Internet sites,
even if not for LLNL or BITNET or the United States Postal Service.

Below is a typescript of compiling, installing, and testing authd 3.01
on a Sun 4. Sure, RFC 931 is limited to the Internet. Sure, RFC 931
doesn't fix TCP's security holes. But it's a damn sight better than
nothing, it's hellishly easy to get going, it helps Internet security
for more than just mail, it will help CERT track network intruders, and
I don't understand the mindset of anyone who would recommend that it
*not* be installed.

(For the people who don't get alt.sources, I've made authd 3.01, my
sendmail and talk patches, and Nick Sayer's nntpd patches available for
anonymous ftp from 128.122.128.22 in pub/hier/inet/rfc931. More coming.)

---Dan

Script started on Wed Feb 13 10:05:04 1991
csh> make
cc -g -o authd authd.c
rm -f tcpuid
ln authd tcpuid
rm -f tcpuname
ln authd tcpuname
cc -g -c authuser.c
cc -g -o test test.c authuser.o
csh> ./INSTALL
Each action will be printed before it is run. Press return to proceed.
1. Install authd, tcpuid, and tcpuname.
! install -c -g kmem -m 02755 authd /etc/authd: 
! rm -f /etc/tcpuid; ln /etc/authd /etc/tcpuid: 
! rm -f /etc/tcpuname; ln /etc/authd /etc/tcpuname: 
2. Install the authuser library.
! install -c -m 0444 authuser.h /usr/include/authuser.h: 
! ar rv /usr/lib/libauthuser.a authuser.o: 
r - authuser.o
! ranlib /usr/lib/libauthuser.a: 
! chmod 644 /usr/lib/libauthuser.a: 
3. Make the man pages available.
! install -c -m 0444 authuser.3 /usr/man/man3/authuser.3: 
! install -c -m 0444 authd.8 /usr/man/man8/authd.8: 
! install -c -m 0444 tcpuid.8 /usr/man/man8/tcpuid.8: 
! install -c -m 0444 tcpuname.8 /usr/man/man8/tcpuname.8: 
4. Make sure an auth port is in /etc/services.
Let me glance at /etc/services for you...
Okay, you have it already. Let's continue.
5. Enable auth in /etc/inetd.conf.
Let me glance at /etc/inetd.conf for you...
Okay, it's already there. That's it!
csh> ./test
system says host is 127.0.0.1
authuser says host is 127.0.0.1
system says username is root
authd says username is root
Everything looks okay to me.
csh> exit
csh> 
script done on Wed Feb 13 10:05:50 1991

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 16:00:45 GMT
From:      xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead)
To:        comp.protocols.ibm,comp.protocols.tcp-ip,alt.sys.sun
Subject:   RPC application programming

In John Corbin's excellent book "The Art of Distributed Applications:
Programming Techniques for Remote Procedure Calls", he hints that one
can write multithreaded RPC (tcp not udp) applications.  Perhaps I am
dense, but I don't quite understand how this is done.  In particular
I am interested in providing an RPC type server on MVS, using
IBM's RPC software.  If anyone has any sample applications showing
how one handles multithreads/streams using RPC please send me mail
   xxbja@csduts1.lerc.nasa.gov
I will be glad to summarize any responses.  By the way any other
references on RPC programming would also be appreciated.
--
Betty Jo Armstead              SVERDRUP Technology Inc.
21000 Brookpark Rd.Ms 142-2
Nasa Lewis Research Center
Cleveland Ohio 44135           From: xxbja@csduts1.lerc.nasa.gov

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 16:34:51 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP code available?

PC/TCP as it presently ships (v2.05) includes an SNMP agent.  I believe that
current production WIN/PC from Wollongong also has one.  I'm not sure that
any other DOS SNMP agents exist.  I believe that both the MIT and CMU freeware
SNMP for Unix packages include an agent.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 17:46:57 GMT
From:      kolb@PHAEDRUS.PSI.COM
To:        comp.protocols.tcp-ip
Subject:   Looking for Router and/or Terminal Server Vendors


	PSI is issuing an RFP for hardware and software to expand and
	enhance it's network and service offering in 1991 and 1992.
	Any router and/or terminal server vendor wishing to participate
	in this RFP program should contact me by 21 February 1991.

	Please send all electronic responses directly to me.  Do *not*
	post them back to the tcp-ip mail list or the comp.protocols.tcp-ip
	news group.

	christopher kolb
	kolb@psi.com
	(703)620-6651
	Performance Systems International, Inc.
	11800 Sunrise Valley Drive, Suite 1100
	Reston, Virginia, 22091

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 18:21:27 GMT
From:      sss@nic.cerf.net (Marlene M. Eckert)
To:        comp.protocols.tcp-ip
Subject:   SLIP & FTP


Hello.  I need help from the experts...

I have SLIP installed on a Sun3 under SunOS 4.1.1.  We are having problems
FTPing large files.  FTP likes to hang up - usually in the same place in the
file.  I do set the file type to binary for binary file transfers.

Any solutions or debugging hints will be most appreciated.  Please e-mail
your responses to me.  I'll summarize for the net if there is interest...

Thanks in advance.

Michael Reznick
Structured Systems & Software (3S)
sss@cerf.net

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 18:30:34 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP "manageability" ?!?

In article <1991Feb13.062435.23866@Think.COM>, barmar@think.com (Barry
Margolin) writes:

|> It's still pretty early in the network management business, and many
|> vendors are just starting to provide SNMP facilities.  Some have
 jumped in
|> feet first, while others are still unsure how it fits in.  For
 instance, I
|> don't think any Unix systems are yet shipping with SNMP support
 (luckily
|> there are publically-available snmpd implementations, of various
 levels of
|> quality).

The last part of this paragraph is no longer true - at least one Unix
vendor, DEC, is shipping an SNMP agent as a standard daemon on all
current systems (as of at least Ultrix 4.1, possibly since Ultrix 4.0).

	--Vince

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 18:52:01 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   RFC-1122 and 1123


In the discussion about UDP checksums, someone wrote to me:

> I have no idea if [name censored] would reply to a bid that required RFC 1122
> conformance and claim conformance.  They don't conform.


As you might guess from my return address, I've no shortage of bids, RFQ's
and RFP's that have either checklist items for "conforms to RFC 112[23]" or
copies of the entire checklists from the RFCs.

Not long ago, a room full of people concerned with such things sat down to
determine the company's official answer.  We started at the beginning,
considering each SHOULD, MAY, CAN, WILL, WON'T, OUGHT, COULD, and
ONLY-IDIOTS-WOULD-DO-OTHERWISE.  We filled many hours with "gee, of course
we do/don't/would/wouldn't do that, but let's check...see the code there
...but look...ok, add to the list for verification."

After lots of this powerful fun, we paused to estimate when we'd be
finished making the list and how long the list would be.  The encouraging
answer was that the list would be finished in only a few months and would
be only a little bigger than the RFC's.

We thought about the effort and considered the size of the existing bug
lists for the areas covered by the RFCs.  We individually compared the
personal satisfaction to be gained from completing the list with other
pursuits like making TCP/IP/FDDI run 30% faster.  Then we considered the
gain to our customers from having less fast, less feature-full, buggier but
"conforming" implementations.

The result is that we will make an honest effort to perpetually look
through the RFCs for real and potential problems, and to add discovered or
reported conflicts to the bug lists to be fixed with the other bugs.
However, we won't claim conformance.  We'll just provide the linage of our
source.  This decision did not make our sales people cry with joy.

In other words, RFC-1122 and RFC-1123 are interesting reading, great guides
for writing or fixing code, and wonderful tools for adjudicating blame
among vendors.  They are terrible conformance standards, at least at this
non-military-standards sort of shop.

I know the response many will have is that 27 gov. agencies and 63
industrial consortia are developing test facilities.  Old and new
experience with test suites such as SVVS and POSIX, to name only two,
make me skeptical of that panacea.

Are there different perspectives from others, outside the gov. agencies,
consortia, etc who want to sell us and our customers their seals of approval?



Vernon Schryver,   vjs@sgi.com

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 19:28:08 GMT
From:      paulf@deere.com (Paul A. Fisher)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Tandem 6530 terminal emulator (tn6530?)


We are looking for a product similar to tn3270, except it emulates a Tandem 
6530 terminal instead of an IBM 3270 terminal.  We now have TCP/IP running on 
our Tandems, but we don't have good terminal access across the network.

We need to run this product on a Sun workstation (Sunview).

We have heard that this product does exist, but so far we have found no leads.

Any information or pointers would be very helpful.

Thanks.


-- 
Paul A. Fisher                    paulf@deere.com
Deere Tech Services               ...uunet!deere!paulf
John Deere Road                   (309) 765-4547
Moline, Illinois 61265

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 19:33:43 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   How can I prevent wrong route queries to a default router?


We have a multi-homed host (doesn't route packets). On one side in the
Internet. On the other side is an internal network that is not
connected to the Internet.

How can I prevent the host from querying the default router (to the
internet) about unknown subnets on the internal networks?

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

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 20:26:28 GMT
From:      fkittred@bbn.com (Fletcher Kittredge)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC application programming

In article <1991Feb13.160045.7947@eagle.lerc.nasa.gov> xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead) writes:
>In John Corbin's excellent book "The Art of Distributed Applications:
>Programming Techniques for Remote Procedure Calls", he hints that one
>can write multithreaded RPC (tcp not udp) applications.  Perhaps I am
>dense, but I don't quite understand how this is done.  In particular
>I am interested in providing an RPC type server on MVS, using
>IBM's RPC software.  If anyone has any sample applications showing
>how one handles multithreads/streams using RPC please send me mail
>   xxbja@csduts1.lerc.nasa.gov

TCP is a protocol definition; support for multi-threaded programs is a
operating system service (if the support is worthwhile).  There is nothing
about TCP that makes it possible to write multi-threaded applications.  So
your sense of the world is correct.

In the distributed applications domain, multi-threaded programs are seen
as a beneficial tool.  The advantage of multi-threaded programs is that
they offer a method of taking inherently asynchroneous processes and allow
programmers to treat functional sections as synchroneous.  Most current
distributed bases provide thread support: mach, amoeba, OSF DCE, etc.
Older distributed bases such as Sun O/S or VMS are planning to add (real)
thread services in the future.

>I will be glad to summarize any responses.  By the way any other
>references on RPC programming would also be appreciated.

There are so many I don't know where to begin.  "Distributed Systems"
Ed. Sape Mullender, 1989, ACM Press is a start.  All of the OSF DEC,
Mach, ISIS, Camelot and Amoeba documentation is relevant.  Of course,
you need the Sun O/S documentation and XDR/RPC sources (available on
uunet.u.net).

>--
>Betty Jo Armstead              SVERDRUP Technology Inc.
>21000 Brookpark Rd.Ms 142-2
>Nasa Lewis Research Center
>Cleveland Ohio 44135           From: xxbja@csduts1.lerc.nasa.gov


Fletcher Kittredge
Platforms and Tools Group, BBN Software Products
10 Fawcett Street,  Cambridge, MA. 02138
617-873-3465  /  fkittred@bbn.com  /  fkittred@das.harvard.edu

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 21:59:23 GMT
From:      chris@endgame.gsfc.nasa.gov (Chris Shenton)
To:        comp.protocols.tcp-ip
Subject:   traffic monitoring by net snooping

I recently saw this clever program from Silicon Graphics which watches
traffic (of a specified protocol, I think) on the ether, and draws lines
connecting machine names -- kind of like a dynamic traffic mapper. They 
called it netsnoop or netlook or some such...

I'd like to try writing something like this but need pointers to the TCP/IP
calls.  I assume I'd be interested in the packet level stuff, just reading
the TO and FROM addresses from the ip headers... Any pointers?

Thanks in advance. Mail and I'll summarize.




--
chris@asylum.gsfc.nasa.gov, ...!uunet!asylum.gsfc.nasa.gov!chris, PITCH::CHRIS

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 22:12:30 GMT
From:      fab@md.interlink.com (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   sequence number bug


Has anyone experienced a bug in any tcp implementation when the sequence
number crosses xxxx0000?  That is it gets stuck when the low order bits
go to all zeros.  A user has experienced this with another implementation
and we want to know if others have seen this before.  The other implementation
is Lachmann, UTS, but I want to know if it has been seen with -this- one
or with ---other--- implementations. 

Please reply if you have seen or heard of this bug in ---any--- implementation.

Fred
------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 22:28:00 GMT
From:      Sabo@DOCKMASTER.NCSC.MIL
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP comparison

Yes, Datapro has completed a study of SNMP-based management stations and
will soon release a report on SNMP-based agent.  The SNMP manager report
is often given away free of charge.  Contact Jill Huntington-Lee at
(800) DATAPRO ex 2444.

L.  Michael Sabo

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 22:49:50 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

>Since the latest release of SunOS has this default wrong, I assumed it
>is 4.2-based (but perhaps they changed the default in the process of
>porting 4.3 TCP/IP,

They did change the default; SunOS 4.0's networking is somewhere between
4.3BSD and 4.3-tahoe based, and 4.1's networking is closer to tahoe.

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      13 Feb 91 23:16:53 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP documents

In article <1991Feb6.172144.12605@nmt.edu> Ruth Milner
   <nraoaoc@nmt.edu> (NRAO Array Operations Center) writes:
>Where can I get some good documentation on SLIP? I have RFC1055, but it does
>not state which of the actual protocols it uses (presumably because it can use
>more than one). Now, I thought it used UDP in most implementations, and I'm 
>trying to convince someone that he's not getting much, if any, error correction
>on his SLIP connections, but he wants actual written proof. He thinks it's 
>using TCP (as in "TCP/IP"), the same as Internet connections on Ethernet links.
>I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is 
>there such a beast?

SLIP sits *UNDER* IP, and will carry any and all IP traffic that the
router sends to the SLIP interface.

The user executes the FTP client program. The FTP specification
(RFC-959) will tell you that FTP uses two simultaneous TCP connections
to do the work. It is possible to use a UDP based protocol to transfer
files. Two examples of UDP based file transfer protocols are TFTP (RFC-783)
and NFS.

Be aware, however, that the error detection capabilites of SLIP are
somewhat weaker than those of Ethernet (or HDLC).

-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 00:07:39 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: fax data over ip anyone?


More info would be appreciated. Thanks in advance.

  George Williams
  gwilliam@sh.cs.net - email
  (617) 873- 3395    - phone


    Date:    11 Dec 90 18:07:09 GMT
    From:    ndsuvm1!mtus5!pecampbe@cunyvm.cuny.edu
    Subject: Re: fax data over ip anyone?

    In my TCP-IP software, there is an unused code segment to do fax transfers
    of some sort. Judging by the looks of it, I think it works through the
    mailer.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 04:35:14 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC-1122 and 1123

In article <85285@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>As you might guess from my return address, I've no shortage of bids, RFQ's
>and RFP's that have either checklist items for "conforms to RFC 112[23]" or
>copies of the entire checklists from the RFCs.

From my minimal experience with RFQ's (one big project about seven years
ago), I don't think such items are a critical factor.

An RFQ typically contains quite a few requirements for a facility, and it's
rare that any vendor can meet all of them.  For instance, a TCP/IP RFQ
might specify conditions on performance, usability, and conformance to a
standard.  Some respondents will do better jobs than others on various
pieces of the requirements; implementation A may conform to the standard
completely, implementation B may have a more complete API, while
implementation C may perform better.  The customer will have to decide
which aspects are more important, and decide among the respondents on this
basis.

A vendor should look upon host requirements RFCs as additional guidelines,
and add them to their to-do lists.  They must still reconcile these with
the problems and suggestions from users, marketing requirements, etc., and
prioritize the list.

When responding to the RFQ, all you can do is hope that your strengths in
other areas outweigh your deficiencies in others.  Of course, if there *is*
a vendor that meets all the requirements, you may be out of luck, but
that's the nature of competitive bidding and the free market.

--
Barry Margolin, Thinking Machines Corp.

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

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 06:47:29 GMT
From:      archx@cheops.UUCP (archx)
To:        comp.protocols.tcp-ip,comp.unix.misc
Subject:   RCP Socket Usage


      We are currently doing a port of NCSA telnet to 3+open sockets.
Having heaps of trouble getting RCP to work. Can anybody help with a
spec/RFC or whatever that might tell us how the internals of unix RCP
works. 

RCP appears to call out on Socket 514, sends "login names" and "rcp -t destination filename" Then it closes Socket 514What happerns after this we don't know !!




Any assistance greatly appreciated.


Thanks in advance

Arch Murphy
EMAIL: archx@cheops.qld.tne.oz.au

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 13:32:16 GMT
From:      vaillan@ireq.hydro.qc.ca (Clement Vaillancourt)
To:        comp.protocols.tcp-ip
Subject:   Re: Subject: traffic monitoring by net snooping

In article <CHRIS.91Feb13165726@endgame.gsfc.nasa.gov> chris@endgame.gsfc.nasa.gov (Chris Shenton) writes:
>I recently saw this clever program from Silicon Graphics which watches
>traffic (of a specified protocol, I think) on the ether, and draws lines
>connecting machine names -- kind of like a dynamic traffic mapper. They 
>called it netsnoop or netlook or some such...
>
>I'd like to try writing something like this but need pointers to the TCP/IP
>calls.  I assume I'd be interested in the packet level stuff, just reading
>the TO and FROM addresses from the ip headers... Any pointers?

I have the real NetVisualyzer package (including netsnoop, netlook, analyzer)
running on an SGI workstation. It is a great package to watch networks in
action. My SGI machine is the only SGI on this research campus watching
the traffic of about 300 Suns... I had to buy the SGI workstation to
be able to run this great package. I never found something as good for the
money running on a Sun.

I just don't understand why SGI don't port this package to Sun and sell it
with a good profit?

Again, a very good package to see and debug networks, no statistics or snmp
in version 1.0 but I heard it is comming.

Clem.
--
   Clement Vaillancourt, Analyste,   |   Institut de Recherche d'Hydro-Quebec
   Responsable du Reseau Ethernet    |        1800 Montee Ste-Julie, Varennes
   (Analyst, Network Manager)        |             P. Quebec, Canada, J3X 1S1
   vaillan@ireq.hydro.qc.ca          |Tel:+1 514 652 8238 Fax:+1 514 652 8309

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 14:57:13 GMT
From:      leo@unipalm.uucp (E.J. Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail


 have a simple way of sending 'registered' mail. I include in it a line

If you recieve this, will you tell me?

This enables me to determine that not only has the message got there,
but also that a human the other end has actually understood it, and was 
sufficiently civilised to inform me of the fact.

A very powerful protocol indeed!

:-)

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 15:00:21 GMT
From:      leo@unipalm.uucp (E.J. Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: NS DP8390 ethernet chip

ash@uupc.omega (Andrew Hardie) writes:

>I seem to remember some months ago talk about problems (dropped packets?)
>with the A and B versions of the DP8390 chip as fitted to the WD8003E.
>I notice that the new boards have the DP8390C chip. Can someone remind
>me what the problem was and whether it (and any others that may have
>existed in the A and/or B versions) were fixed in the C revision.
>Thanks
>-- 
 
>Andrew Hardie                                       ash@omega.uucp
>London, England                                ukc!cctal!omega!ash

Include me in your mailing lists too - Russ? James? 

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 15:00:41 GMT
From:      dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty)
To:        comp.protocols.tcp-ip
Subject:   (none)

Mike Brown receintly asked (<1991Feb12.042501.6758@cec1.wustl.edu>)

>I recently learned that a major U.S. router vendor defines SNMP management
>as the ability to "monitor" their equipment via SNMP and not the
>configuration of the equipment via SNMP.  I believe that I understand
>the security problems related to SNMP and why caution must be exercised
>with the use of SNMP to configure network elements.  I still believe that
>SNMP can be an effective configuration mechanism in certain networks.
>
>
>My question is:  Does any router vendor support configuration via SNMP?
>
>If you think I am naive for using SNMP to configure network elements then
>please let me know...
>
>	Regards,
>	Mike Brown	Corporate Telecommunications
>			Information Systems
>			One Bell Center, Rm 24-V-5
>			Southwestern Bell Telephone Co.
>			St. Louis, MO  63101
>			(314) 235-7863

I'm not speaking for Network Systems, but I do have a little information
you can use as you will.  In theory, SET allows a client to manipulate
variables that could control router parameters.  In fact, RFC 1157 (I
think that's the right number) gives an example of using a
"NumSecondsToReboot" variable to perform this kind of task, rather
than having to implement a "Reboot" command in the agent.  So the
theoretical answer to your question is yes.

However, there are a number of security issues here (I know that
security isn't a popular topic with a lot of people, but I invite you to
read Cliff Stoll's "The Cuckoo's Egg" before skoffing in my direction).
People I talk to in development don't think that the community mechanism
provides enough security, and say that developers in other companies
feel the same.  In any case, I havn't heard of anyone who lets you muck
with their router configuration via SNMP.

I hear that there's an SNMP Authentication RFC somewhere in the mill.
Perhaps someone else can shed some light on that.  

As a practical solution for you, can't you use Telnet?  Everyone
supports it, and this way your door isn't COMPLETELY unlocked (just
mostly unlocked).

-----------------------------------------------------------------------------
Ted Doty                     | tel. +1 301 596-2270
Network Systems Corp.        | voice mail (800) 233-1485 x4436
ted.doty@network.com         | fax: +1 301 381 3320
-----------------------------------------------------------------------------
These views are my own, not Network Systems'.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 15:17:52 GMT
From:      rauscher@remus.rutgers.edu (Trott ++)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP for MAC

>We are interested in finding a good tcp-ip system for Macintosh computers
>using ethernet.  

Try a product called MacTCP.  It's commercial, but it seems to be quickly
becoming the standard for TCP/IP with Macintoshes.


>                   We would like for the Macs to be NFS clients using a SUN
>as an NFS server.  

Does it have to be NFS?  There is a popular package call AUFS
(Apple-Unix File Server) which allows you to mount Sun files on
your Macintosh.  Besides, if it were true NFS, you may run into
problems with the differences between file formats of Macintosh  
and unix files( Mac files are split into data and resource forks,
etc.).  AUFS is part of a large package that allows your unix
boxes and Macintosh to talk nicely.  It is available via anonymous
ftp to rutgers.edu.  It is in src/ru-cap2.tar.Z.  It is based
on the Columbia Appletalk Protocol (CAP).  Rutgers has been
successfully running this for a couple years.


>                      We also need mail running on the Macs that can send and 
>receive from SMTP.  Thanks for any sugestions.  We are particularly interested
>in hearing from users who have successful systems running.

A possible solution to this is POP Mail.  (please refer to the 
rfc for it -- I don't know the number off the top of my
head).  In short, mail would be delivered to your unix box and sit
there until your macintosh user asked for it (all done with some
sort of nice interface).  

>					Gene Jackson
>					jackson@bdrc.bd.com

-Rich Rauscher

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 15:59:00 GMT
From:      wayne@penril.UUCP (Wayne Chuu)
To:        comp.protocols.tcp-ip
Subject:   Looking for Telnet Course



I am desperately looking for some TELNET courses.
Whoever knows such information, please let me know. Your help
is appreciated.


Wayne Chuu

Please reply to one of the addresses below:

uunet!penril!louis!wayne
penril!louis!wayne@uunet.UU.NET

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 16:24:29 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams)
To:        comp.protocols.tcp-ip
Subject:   Registered SMTP

I dropped off a couple of messages supporting a "return receipt" registration
feature for SMTP a while ago.  In thinking about the issue some more, and
reviewing people's worries about excess flurries of acknowledgements being
generated by mailers along the line, it has occurred to me that the 
return message should not be part of SMTP but rather be part of the user's
mail interface.  The only thing that SMTP should support is some sort of 
header line that the mail application can use to determine whether or not
a return message should be sent when the user displays (ok, we can't tell
whether it's actually READ or not) the received message.  I think this
approach is more logical; SMTP almost certainly should not get involved in
sending "I got it" messages anywhere on its own.

Thoughts?

BTW, I still think the capability is needed -- it just needs to be identified
in the right category.

Mark

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 17:04:36 GMT
From:      kevinr@tandem.Tandem.COM (Kevin J. Rowett)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Tandem 6530 terminal emulator (tn6530?)

In article <626@deere.com>, paulf@deere.com (Paul A. Fisher) writes:
|> 
|> We are looking for a product similar to tn3270, except it emulates a Tandem 
|> 6530 terminal instead of an IBM 3270 terminal.  We now have TCP/IP running on 
|> We have heard that this product does exist, but so far we have found no leads.

One exists. It's called TN6530. It comes with the TCP/IP S/W you order from
Tandem.

kevinr@tandem.com

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 18:10:40 GMT
From:      ken@dali.gatech.edu (Ken Seefried iii)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP "manageability" ?!?

In article <1991Feb13.103034@Valinor.Stanford.EDU> vaf@Valinor.Stanford.EDU (Vince Fuller) writes:
>
>The last part of this paragraph is no longer true - at least one Unix
>vendor, DEC, is shipping an SNMP agent as a standard daemon on all
>current systems (as of at least Ultrix 4.1, possibly since Ultrix 4.0).
>

IBM ships SNMP for AIX on the RS/6000's.   

--

	ken seefried iii	"Specialization is for insects."
	ken@dali.cc.gatech.edu	   - Robert A. Heinlein (1916-1988)

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 18:20:44 GMT
From:      c_rstine@HNS.COM (Robert Stine)
To:        comp.protocols.tcp-ip
Subject:   ioctl() and getsockopt()

Sorry if this is too BSD-centric, but is there a way to get the value
of SO_SNDBUF and SO_RCVBUF by using ioctl(), instead of getsockopt()? 
If so, what are the ioctl commands?

Thanks,

Bob Stine
(w) c_rstine@hns.com
(h) bstine@MCIMail.com

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 18:36:09 GMT
From:      russ@sail.LABS.TEK.COM (russ)
To:        comp.protocols.tcp-ip
Subject:   PPP for bsdOS


	I've been attempting to bring up the PPP package on our
sun3 running MtXinu MSD2.6. Reading the Jan 7 issue of UNIX Today gave 
an FTPable source for PPP on bsdOS - namely lancaster.andrew.cmu.edu 
	Unfortunately the PPP.shar file that you get seems to be incomplete.
logwtmp.c is missing. The kernel side of it is complete, and installed in
our system already,  but this module is missing for building the user
level 'ppp' program. I haven't been able to get the needed module from the
author, so I'm looking for other FTPable sites that have a PPP kit for bsdOS.
Or if perchance one of you have this kit and can direct me to a copy of the
needed module. I of course could write my own, but that would take longer than
writing this letter.
	Any information would be helpful, but please don't direct me to
omnigate or uunet for SunOS sources.
	Thanks heaps,

		-russ

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 19:33:21 GMT
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        comp.protocols.tcp-ip
Subject:   (none)

Anyone care to take a shot at this one ?

In the Host Requirements RFC (Section 4.2.3.8.  Page 103) it says,

	"When a TCP connection is OPENed passively and a packet 
	arrives with a completed IP Source Route option (containing 
	a return route), TCP MUST save the return route and use it 
	for all segments sent on this connection..."

Ok, fine.  But does this mean the passive end of the connection cannot 
issue a source route of its own?  Note that the preceding paragraph of 
the RFC says 

	"An application MUST be able to specify a source route when 
	it actively opens a TCP connection, and this MUST take
	precedence over a source route received in a datagram."

Where did this received source route come from if the passive end
has to save a received return route (presumably received from the 
actively opened end) and 'use it for ALL segments sent on this 
connection' ?

Thanks in advance,

Richard Gralnik
(rlg@desktalk.desktalk.com)

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 20:15:25 GMT
From:      woods@ncar.ucar.edu (Greg Woods)
To:        comp.protocols.tcp-ip
Subject:   third-party traceroute

I have heard that there is a third-party version of "traceroute" available
(third-party traceroute means the ability to find out how a packet travels
from point A to point B when you are at neither point A nor point B). Is
this true, and if so, where can I obtain it?

--Greg

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      14 Feb 91 23:22:16 GMT
From:      ables@lot.ACA.MCC.COM (King Ables)
To:        comp.protocols.tcp-ip
Subject:   rudp

Can someone give me a pointer to info about rudp?

I hear it's a reliable implementation of UDP developed
at Berkeley, but that's all I know... a pointer to an
ftpable paper or something would be appreciated.  Thanks.
-----------------------------------------------------------------------------
King Ables                    Micro Electronics and Computer Technology Corp.
ables@mcc.com                 3500 W. Balcones Center Drive
+1 512 338 3749               Austin, TX  78759
-----------------------------------------------------------------------------

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 00:04:14 GMT
From:      lwallace@javelin.es.com (Lynn Wallace)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   How to get remote ethernet address?


We use dedicated ethernet connections between machines, meaning a machine on
each end of a cable with no other connections.  The system I am writing (or
attempting to :-) a driver for will be connected to various machines, sometimes
"right off the assembly line".  Is there a way to obtain the remote's ethernet
address (vs. internet address; it's a low-level protocol) from software so the
user doesn't have to flip through a manual, eyeball a card or peek memory to
get it?

Reply via e-mail please, as I don't usually follow these groups.  Thanks!

-- 
Lynn Wallace			   |I am not an official representative of
Evans and Sutherland Computer Corp.| <- E&S.  Or for that matter, unofficial.
Salt Lake City, UT 84108	   |Internet: lwallace@javelin.sim.es.com
			War not make one great! -- Yoda

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 01:02:33 GMT
From:      Murray_RJ@cc.curtin.edu.au (Ron Murray)
To:        comp.protocols.tcp-ip
Subject:   PPP Documentation wanted


   I'd like to get the specs for PPP. RFC number (if any) or other help
would be appreciated.
Thanks,
....Ron

-- 

===============================================================================
 Internet: Murray_RJ@cc.curtin.edu.au                | "You can lead a horse to
 ACSnet: Murray_RJ@cc.cut.oz.au                      | water, but if you can
 Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet    | get him to float on his
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
               TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
===============================================================================

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 06:56:10 GMT
From:      dbjoyner@eos.ncsu.edu (David Joyner)
To:        comp.protocols.tcp-ip
Subject:   Re: traffic monitoring by net snooping

In article <CHRIS.91Feb13165923@endgame.gsfc.nasa.gov>,
chris@endgame.gsfc.nasa.gov (Chris Shenton) writes:
> I recently saw this clever program from Silicon Graphics which watches
> traffic (of a specified protocol, I think) on the ether, and draws lines
> connecting machine names -- kind of like a dynamic traffic mapper. They 
> called it netsnoop or netlook or some such...
> 
> I'd like to try writing something like this but need pointers to the TCP/IP
> calls.  I assume I'd be interested in the packet level stuff, just reading
> the TO and FROM addresses from the ip headers... Any pointers?
> 
> Thanks in advance. Mail and I'll summarize.
> 

I am also interested in this subject.  I do know that it is possible
to put an ethernet adapter into "promiscuous mode" where it receives
all packets on the network.  I do not know exactly how this is done
(I think via ioctl calls) or where the packets are queued/stored by the
ethernet adapter.

This doesn't exactly seem like the best newsgroup for information on
ethernet, but what is???

+===========================================================================+
| David B. Joyner (dbjoyner@eos.ncsu.edu) | North Carolina State University |
 +---------------------------------------------------------------------------+
|   "Typically supercomputers use a single microprocessor." -Boston Globe   |
 +===========================================================================+

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 08:14:16 GMT
From:      enag@ifi.uio.no (Erik Naggum)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

> Erik Naggum, Naggum Software, Oslo, Norway, offered a thoughtful
> rebuttal to the idea of certified/registered mailers.  However, I
> believe that his arguments overlook several issues:

Let me try to reply to the overlooked issues.

> 1) Many organizations do use registered mail, or some other feedback
>    mechanism, to verify that deliveries have been made.  The absence
>    of comparable mechanisms in SMTP is perceived as a shortcoming
>    that must be tolerated, at best.

The postal service is paid to deliver your mail.  When you buy the
service of registered mail, the postal service is required by law to
deliver it and record the delivery in a way which you can rely on,
legally.  You can request return receipts from the postal service as
well, and the postal service has a big problem if you don't get a
return receipt when the letter was received.  There is no one who can
assume this responsibility in the Internet.  Thus, the "shortcoming"
stems from the nature of the service provider involved, and SMTP
reflects this.

> 2) Many non-SMTP mail systems, especially those running on PCs and
>    LANs, offer registered mail capabilities, making the absence of
>    those capabilities in SMTP more obvious and irritating than they
>    might be otherwise.

I've seen systems which do this, but they are in no way legally
binding, which registered mail is in its postal implementation they
try to mimic.  In particular, you can't guarantee that non-delivery of
a delivery notification is equivalent to non-delivery of the message,
which I spent some time indicating.  The other problem is that a
confirmed delivery may not be equivalent to confirmed receipt by the
intended recipient: the recipient may have elected to "share" his
account with somebody else, the mail reading program may have crashed
before he had a chance to read the message, he only read the header of
your message and accidentally deleted it, he used the editor to read
his mailbox and deleted it before any mail reader had a chance to send
a delivery notification back.  The list goes on.  None of these apply
to postal registered mail, because the recipient actually has to sign
a form which agrees that he has received it, and the person requesting
such signature may also request proof that the signer is the intended
recipient.  Another technicality is that the intended recipient may
refuse to accept the letter.  Also, registered mail is returned to the
sender if the recipient has not been able to receive it within a
certain time.

To successfully mimic the registered mail option of postal services, a
whole new system has to be implemented wherein some special recipient
on the target system receives the message, sends a message to the
intended recipient informing him of the message, with a copy of the
envelope and possibly headers, whereupon the intended recipient has to
submit a privacy-enhanced request to receive it, which is construed to
be evidence that the message has been received and presumably read by
the intended recipient.  Some amount of authentication and confirmable
action to receive the message is needed.

> 3) The ACK/NAK problem can be as troublesome on LANs as it would be
>    on the Internet.  The fact that LANs supporting registered mail
>    schemes do not typically collapse due to ACK/NAK cascades
>    indicates that the real world can cope with mail registration
>    successfully.

True, they can.  All major protocols also cope with the Three Armies
problem, but I've come across unilaterally hung X.25 connections so
often that I believe it's a real problem.  TCP connections time out
after too many retries, but retries is a central part of it all.  The
question remains that in the absence of confirmable delivery and a
confirmed delivery notification, should the sender resubmit the
message until such is received?  Of course, often it will work, but
it's the cases where it doesn't that you really need the services of
registered mail.

> 4) E-mail is certainly not the only means of communications
>    available to most Internet users.  The lack of a receipt notice
>    usually prompts our users to call the intended recipient to alert
>    him/her to the presence of the mail.  This feedback opportunity
>    can assist network administrators in identifying the existence of
>    network problems if, for instance, the mail was never received.

Exactly right!  Therefore, since it's intractable to solve the problem
of registered mail in the Internet, the services of the telephone, the
telefax, and the postal registered mail may be used with more success
than that with which we may try to implement registered mail in the
Internet.  With the advent of Privacy Enhanced Mail, I think we will
attain a higher level of certainty with respect to authenticity, but
the problem of confirmed delivery remains to be solved.  As I alluded
to above, a registered mail daemon using PEM may be a viable solution
where PEM is available.

> Registered mail is certainly no panacea for assuring effective
> communications.  It can, however, provide important information for
> users and is in appreciable demand in some environments.

I don't disagree with this, I just think it's technically infeasable
at the moment and will remain so for a long time.  Especially as long
as we don't have a contractual agreement between service provider and
service user as to the delivery status of mail.

Personally, I call people, or ask them to call me when an important
issue has to be resolved.  This invariably works well.

--
[Erik Naggum]					     <enag@ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik@naggum.uu.no>

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 13:07:00 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   Re: traffic monitoring by net snooping

In article <1991Feb15.065610.1371@ncsu.edu> dbjoyner@eos.ncsu.edu (David Joyner) writes:
>In article <CHRIS.91Feb13165923@endgame.gsfc.nasa.gov>,
>chris@endgame.gsfc.nasa.gov (Chris Shenton) writes:
>> I recently saw this clever program from Silicon Graphics which watches
>> traffic (of a specified protocol, I think) on the ether, and draws lines
>> connecting machine names -- kind of like a dynamic traffic mapper. They 
>> called it netsnoop or netlook or some such...
>> 
>> I'd like to try writing something like this but need pointers to the TCP/IP
>> calls.  I assume I'd be interested in the packet level stuff, just reading
>> the TO and FROM addresses from the ip headers... Any pointers?
>> 
>> Thanks in advance. Mail and I'll summarize.
>> 
>


   I too am interested in any kind of ethernet snooping with a Unix
preferably BSD flavor machine - promiscuousness (sp?) is right up
my alley.

                               Jerry Freedman,Jr

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 14:47:35 GMT
From:      NELSON@MSU.BITNET ("Doug.Nelson")
To:        comp.protocols.tcp-ip
Subject:   Re: Problem with WIN/TCP's secure FTP

From Merton Campbell Crockett:

> The copy of RFC959 that I have indicates that a command is a "TELNET string"
> and that the command verb is terminated by a space.  It also states that
> command arguments or parameters are separated by one or more spaces.  I didn
> find any explicit comments on trailing spaces.  Leading spaces, on the other
> hand, are addressed and permitted.
>
> While one might argue that Wollongong's construction of the command is shodd
> the NOS/VE and IRIS command parsers err in not being "robust".

I'll (gladly) stand corrected.  I had looked for any reference to multiple
spaces, and read right over the sentence that says it (in section 5.3)
at least twice.  Now that I see that, I would say that such a command
should be treated as giving a null pathname, which is equivalent to the
default.  I was originally going to make the same statement about the
NOS/VE and IRIS implementations, but without the "or more" clause there,
they would have been correct.

Doug

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 15:39:37 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: NS DP8390 ethernet chip

I would have sent this privately, but I didn't feel any real optimism about
the return address given...

The worst problem that early DP8390 LAN chips had was a tendency to glitch
their byte-order control register, and change byte-orders in the middle of
a packet.  A bit destructive to one's data, that.  The C chips are better
than the A and B, but I think E or F is current these days.  You have to
get the old errata sheets for full details, since the newer ones only list
problems found since C or so.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 16:17:20 GMT
From:      scott@stl.stc.co.uk (Mike Scott)
To:        comp.protocols.tcp-ip,comp.lang.c,comp.lang.c++,comp.os.os2.misc,comp.os.os2.programmer
Subject:   problem using ftp's pc/tcp with zortech C

We recently purchased pc/tcp for os/2 intending to use it in
conjunction with the zortech c/c++ compiler. What the advertising
literature (and salesman) failed to mention was that using the
supplied pc/tcp libraries with anything other than microsoft C isn't
supported - and indeed it won't work with the zortech system :-(. The
distributors in the UK (Unipalm) have been somewhat unhelpful (they
did offer us a refund though!)

Has anyone tried using this combination and got it to work? We need
help urgently as success of a project depends on it!

(I should add that the implementation is very complete, and the
supplied utilities - ftp(d), routed, telnet(d), etc) seem to work
well.)






--
Regards.    Mike Scott       STL, London Road, Harlow, Essex  CM17 9NA, UK
scott@stl.stc.co.uk <or> ...uunet!mcsun!ukc!stl!scott <or>
PSI%234237100122::SCOTT        phone +44-279-429531 xtn 3133.

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 16:21:00 GMT
From:      axw@RELAY.PROTEON.COM
To:        comp.protocols.tcp-ip
Subject:   re: SNMP Authentication

Ted Doty commented about SNMP authentication:

>          However, there are a number of security issues here (I know
>          that security isn't a popular topic with a lot of people,
>          but I invite you to read Cliff Stoll's "The Cuckoo's Egg"
>          before skoffing in my direction).  People I talk to in
>          development don't think that the community mechanism
>          provides enough security, and say that developers in other
>          companies feel the same.  In any case, I havn't heard of
>          anyone who lets you muck with their router configuration
>          via SNMP.
 
>          I hear that there's an SNMP Authentication RFC somewhere in
>          the mill.  Perhaps someone else can shed some light on
>          that.
 
>          As a practical solution for you, can't you use Telnet?
>          Everyone supports it, and this way your door isn't
>          COMPLETELY unlocked (just mostly unlocked).


          It's interesting that SNMP authentication is considered too
          weak, while telnet authentication is strong enough.  SNMP
          and telnet protocols both authenticate with ASCII plaintext
          passwords.  telnet authentication appears stronger since
          it's harder to read a password on a typical host computer. 
          But once you get an analyzer on the network, there's no
          difference!


 Asher Waldfogel

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 16:32:53 GMT
From:      erick@sunee.waterloo.edu (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP comparison

In article <910213222818.739698@DOCKMASTER.NCSC.MIL> Sabo@DOCKMASTER.NCSC.MIL writes:
>Yes, Datapro has completed a study of SNMP-based management stations and
>will soon release a report on SNMP-based agent.  The SNMP manager report
>is often given away free of charge.  Contact Jill Huntington-Lee at
>(800) DATAPRO ex 2444.
>

A non-800 number or E-mail address would be nice for non US sites.

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke                                       Watstar Computer Network
Watstar Network Guy                                   University of Waterloo
Erick@Development.Watstar.UWaterloo.ca              (519) 885-1211 Ext. 2965

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 17:52:30 GMT
From:      mjhammel@Kepler.dell.com (Michael J. Hammel)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   what cards supported with Netwatch?

I fetched both the sources and binaries for Netwatch (the latter from
windom.ucar.edu).  The binaries seem to work but don't seem to be seeing
any traffic.  I ran custom and set the IP address and ethernet address
(good thing I had the docs from MIT's source distribution, its not
plainly obvious the ethernet value has to be in octal!).  I'm using a
wd8003E.  Is this card not supported by Netwatch?  I couldn't find any
reference as to what cards it does support?  My I/O, base memory,
and IRQ values have all been set correctly too (280, d0000, and 5).  

Any ideas out there?

Michael J. Hammel        | mjhammel@{Kepler|socrates}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel
#define CUTESAYING "Lead, follow, or get the hell out of the way."

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 18:23:04 GMT
From:      jeff@dwerger.UUCP (Jeffrey E. Finucane)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Blocking read() using SCO Xenix 2.3.2 and Racal/Interlan NP621-386


   I open a tcp socket using Racal's socket library and later do a read
on that socket.  I expect the read to block indefinitely, but after a few
minutes, the read returns leaving errno == ECONNRESET.  The other end of the
socket is not being manipulated -- that program is awaiting user input.  Is
this poor behavior or am I missing somthing?  Has anyone else experienced this?

  Thanks,
   Jeff


-- 

Jeffrey E. Finucane     Custom Tailored Systems    nshore!dwerger!jeff
Data Phone: (216) 935-2712  Telebit Trailblazer  Voice: (216) 935-0252

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 18:34:50 GMT
From:      car@trux.UUCP (Chris Rende)
To:        comp.protocols.tcp-ip
Subject:   Testing if a host is up

I have a shell script which does a FTP of a file over to another host.

I need a way to put a test ahead of the FTP that will determine whether
or not the other host is "up".

Here is what I have so far:

--------------------------------------------------------------------
# hostup - Written 01/30/91 by Chris Rende
# Last change: 01/30/91 by Chris Rende

x=`ping HOST 56 1 | fgrep packets | cut -c24`

if [ $x = 0 ]; then
	echo "HOST is down"
	exit 1
fi

echo "HOST is up"
exit 0
--------------------------------------------------------------------

Is there a better way? (I.e., more robust, less kludgy).
C program(s) welcome.

car.
-- 
Christopher A. Rende           Central Cartage (Nixdorf/Pyramid/SysVR2/BSD4.3)
uunet!edsews!rphroy!trux!car   Multics,DTSS,Unix,Shortwave,Scanners,UnixPC/3B1
trux!car@uunet.uu.net          Minix 1.2,PC/XT,Mac+,TRS-80 Model I,1802 ELF
trux!ramecs!car     "I don't ever remember forgetting anything." - Chris Rende

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 19:47:02 GMT
From:      kasten@europa.clearpoint.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  Are There Standards For Secure Mail Transfer Via SMTP?


 > From tcp-ip-RELAY@NIC.DDN.MIL Fri Feb 15 01:02:31 1991
 > From: portal!cup.portal.com!Will@apple.com  (Will E Estes)
 > Organization: The Portal System (TM)
 > Subject: Are There Standards For Secure Mail Transfer Via SMTP?
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > Can someone briefly discuss any standards that might exist, or be
 > in the process of development, for the sending of secure mail via
 > SMTP or via the Internet.  Also, are there any relevant RFCs on
 > this topic?
 > 
 > Thanks,
 > Will Estes        (apple!cup.portal.com!Will)
 > 

Will,

Try the following RFC's

Frank Kastenholz
Clearpoint Research

-------

1115  Linn, J.  Privacy enhancement for Internet electronic mail: Part III -
      algorithms, modes, and identifiers [Draft].  1989 August; 8 p. (Format:
      TXT=18226 bytes)

1114  Kent, S.T.; Linn, J.  Privacy enhancement for Internet electronic mail:
      Part II - certificate-based key management [Draft].  1989 August; 25 p.
      (Format: TXT=69661 bytes)

1113  Linn, J.  Privacy enhancement for Internet electronic mail: Part I -
      message encipherment and authentication procedures [Draft].  1989
      August; 34 p. (Format: TXT=89293 bytes)  (Obsoletes RFC 989, RFC 1040)

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 20:00:34 GMT
From:      kasten@europa.clearpoint.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   (none)


 > 
 > [stuff deleted about sucrity in SNMP, sets, and the like]
 >
 > I hear that there's an SNMP Authentication RFC somewhere in the mill.
 > Perhaps someone else can shed some light on that.  
 >
There are four documents under development by the SNMP
security working group. They are currently available as
INTERNET-DRAFTS. The names are:
	 draft-ietf-snmpauth-authsnmp-02.txt
	 draft-ietf-snmpauth-communities-01.txt
	 draft-ietf-snmpauth-manageobject-02.txt
	 draft-ietf-snmpauth-uu-00.txt

These documents describe three schemes for SNMP security:
	1 - trivial -- the current scheme
	2 - authenticated -- provides assurance that
	    the SNMP PDU came from who it purports to
 	    come from and that it has not been tampered
            with along the way, and
        3 - Private -- like authenticated, but is also
            encrypted so as to provide privacy.

Every effort is being made to complete these documents as
soon as possible and have them sent up to the IAB for
publication as an RFC with "Proposed Standard" status.
There is some expectation that this will be accomplished
at the next IETF meeting (in about a month).

Cheers
Frank Kastenholz
Clearpoint Research Corp.          

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 20:03:54 GMT
From:      rah@sppy00.UUCP (MOORE ROBIN)
To:        comp.protocols.tcp-ip
Subject:   Telnet and CR/LF

Can anyone help me understand this problem, and hopefully correct it?

We have an application running on an IBM 3090, which is accessed via
IBM's Telnet server software.  The application typically outputs an
entire 24 x 80 screen of data at a time.  Occasionally, a line of text
towards the bottom of the screen will write over the previous line.
The problem has been experienced running a Telnet client from both
Pyramid and Sun 3 systems.

Placing a LAN analyzer on the net, we have determined two things;
I'm not sure if both of them pertain to the problem, or just the
second one.

   1) It appears that the IBM Telnet software is changing every
   occurance of CR LF in the output into the sequence CR NUL CR LF.
   Reading over RFC 854, it sounds like it would not be unusual to
   convert CR LF to CR NUL, but including both seems strange.
   Perhaps this is because the IBM typically negotiates the terminal
   type of the connection down to the simplest, line-by-line type
   terminal available?

   2) The problem of the overwritten line is seen when segmentation of
   the message occurs between the 2nd CR and the LF.  In other words:
	First packet:   ... Text_of_line_x CR NUL CR
	Second packet:  LF Text_of_line_y CR NUL CR LF ...
   Line y is overwritten by line x.

Should IBM's software be refusing to split the message between these
characters?  This seems unlikely, since I would expect the act of
segmentation to be done in the Transport layer by TCP.

On the other hand, are the Pyramid and Sun Telnet clients both faulty
in their handling of the CR LF when it crosses message boundaries?

Thanks in advance for your assistance, Robin

-- 
{     %              Robin A. Hermance-Moore                 OCLC Inc.        }
{ %%% %%% %% %%%%%   sppy00!rah@cis.ohio-state.edu <== 1st   6565 Frantz Road }
{ %   % %    % % %     OR:  rah@rsch.oclc.org      <== 2nd   Dublin, OH 43017 }
{ %   % %    % % %   OCLC => "Services for Libraries"        (614) 764-6215   }

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 20:12:17 GMT
From:      bogaart@lager.serc.nl (Eugene  Bogaart)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over X25


I am wondering if there are sofware products which can route tcp/ip
into X.25 package over an asynchronous communication port (RS232C or
like wise) following the RFC 877 standard.

Several questions: 

Are there any products which function known. I am particularly
interested in software for DEC/Ultrix, SunOS, HP9000 architectures ?

What is the maximum speed that is supported by such a product ? Most
kernels donot support very high speeds. Ultrix for instance does not
allow 19Kb or higher. Sun and HP do allow 19Kb transfer rates !



Descriptions of actual working configurations are of my interest. Am I
not interested in machine independent hardware solution such as a Cisco
box.


Thanks,

Eugene Bogaart




--

Name:     Eugene Bogaart | Software Engineering Research Centre 
Email:   bogaart@serc.nl | Lange Viestraat 365  3511 BK Utrecht
Phone:	 +31 30 32 26 40 |           P.box 424  3500 AK Utrecht
Fax:     +31 30 34 12 49 |                      The Netherlands
---------------------------------------------------------------
Home phone:+31 838051889 |              De Wiek 93, 6712 JC Ede

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 20:40:48 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Subject: traffic monitoring by net snooping

In article <5455@s3.ireq.hydro.qc.ca>, vaillan@ireq.hydro.qc.ca (Clement Vaillancourt) writes:
> ...[very nice, kind words deleted]...
> 
> I just don't understand why SGI don't port this package to Sun and sell it
> with a good profit?


The software business is much harder to survive than the hardware
business.  It is particularly difficult to start doing software only
products in a hardware company.  It would very difficult to convince the
majority of this company to support a port to compeating hardware.

Trying to keep up with and properly filter network traffic from an Ethernet
or FDDI MAC in promiscuous mode requires substantial support below the
application.  Such support, if present, is not currently likely to be
sufficiently similar on products from hardware vendors.



Vernon Schryver,   vjs@sgi.com

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 21:16:10 GMT
From:      rama@bgsuvax.UUCP (Sub Ramakrishnan)
To:        comp.protocols.tcp-ip
Subject:   How to find directory of rpc services?


I have a question for those SUN rpc gurus.
Background: The portmapper daemon (on port # 111) helps clients
find server programs. Servers register their services with the
portmapper. The client call goes to port # 111; portmapper
returns the port # of the server in its reply message. 
The client can then sends rpc messages to this port #.

Question: How does a client find the "directory" of services
(service name, port # and a description) offered on a  machine.
The client knows neither the name nor the server port #.
Two ways that I don't like:
(1). The client can exhaustively poll all possible port #s.
(2)  Read /etc/services file; does'nt give you services that "come & go".
I am looking for ways to find the services at run time.
Much appreciated.
sub ramakrishnan       rama@truth.bgsu.edu    Voice: 419 372 2337

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 23:05:22 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Configuration via SNMP

In article <9102141500.AA14166@nscultrix1.network.com> dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) writes:
>  In any case, I havn't heard of anyone who lets you muck
>with their router configuration via SNMP.

I believe cisco routers support this.  When enabling SNMP, you can specify
which communities are allowed read-write access.  Further, you may specify
an access list, which restricts which hosts may send SNMP commands using a
particular community name.

I think Cabletron repeaters and bridges can also be configured using SNMP.
I don't know what kind of access control they use.  Their non-SNMP remote
configuration software (Remote LanView) requests a password, but I think it
is only used to authenticate the user locally by the PC running the
management software, not between the PC and the network devices.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 23:46:03 GMT
From:      spgdrp@GANGES.UCOP.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: third-party traceroute


    I have heard that there is a third-party version of "traceroute" available
    (third-party traceroute means the ability to find out how a packet travels
    from point A to point B when you are at neither point A nor point B). Is
    this true, and if so, where can I obtain it?

There is a public domain version of traceroute posted on zerkalo.harvard.edu.
I don't know if this is the canonical source.
You should know that this program requires modifying your kernel.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      15 Feb 91 23:57:15 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over X25

In article <BOGAART.91Feb15151217@lager.serc.nl> bogaart@lager.serc.nl (Eugene  Bogaart) writes:
>I am wondering if there are sofware products which can route tcp/ip
>into X.25 package over an asynchronous communication port (RS232C or
>like wise) following the RFC 877 standard.
>
>Several questions: 
>
>Are there any products which function known. I am particularly
>interested in software for DEC/Ultrix, SunOS, HP9000 architectures ?

SunLink X.25 implements RFC877 for SunOS.  The manual mentions one minor
difference between its implementation and the RFC, though.  Rather than
creating and clearing X.25 virtual circuits dynamically, they must be
created and cleared explicitly by using the x25enable and x25disable
commands.

>What is the maximum speed that is supported by such a product ? Most
>kernels donot support very high speeds. Ultrix for instance does not
>allow 19Kb or higher. Sun and HP do allow 19Kb transfer rates !

According to the manual, 19.2Kbps is the maximum speed using the CPU board
serial ports, but you can go up to 64Kbps using an MCP or SCP.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 01:03:30 GMT
From:      bstrand@poplar13.cray.com (Brad Strand)
To:        comp.protocols.tcp-ip
Subject:   Re: How to find directory of rpc services?

In article <6988@bgsuvax.UUCP> rama@bgsuvax.UUCP (Sub Ramakrishnan) writes:
>
>Question: How does a client find the "directory" of services
>(service name, port # and a description) offered on a  machine.
>The client knows neither the name nor the server port #.
>Two ways that I don't like:
>(1). The client can exhaustively poll all possible port #s.
>(2)  Read /etc/services file; does'nt give you services that "come & go".
>I am looking for ways to find the services at run time.

Use "pmap_getmaps()".  It takes a pointer to a sockaddr_in structure
for the remote host, and returns a pointer to a pmaplist structure.
If you've got source for rpcinfo, look how that program does it.

>Much appreciated.
>sub ramakrishnan       rama@truth.bgsu.edu    Voice: 419 372 2337

BDS

--
Brad Strand		bstrand@cray.com (DOMAIN) uunet!cray!bstrand (UUCP)
Cray Research, Inc.	Networking and Communications Development
655F Lone Oak Drive	#include <std/disclaimer.h>
Eagan, MN 55121		"No gnu taxes."

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 01:48:41 GMT
From:      mogul@wrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Subject: traffic monitoring by net snooping

In article <85756@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Trying to keep up with and properly filter network traffic from an Ethernet
>or FDDI MAC in promiscuous mode requires substantial support below the
>application.  Such support, if present, is not currently likely to be
>sufficiently similar on products from hardware vendors.

I've ported a number of such programs, and (if the program structure
is at all modular) it turns out to be pretty easy to get a program
(e.g., tcpdump, nfswatch, statspy) to run on the following systems:
	Ultrix + Ultrix packet filter
	SunOs + NIT
	4.xBSD + new "Berkeley Packet Filter" (BPF)
and possibly the IBM RT using the modified Stanford packet filter done
by some folks at Merit.

True, all of these facilities have evolved from the same base
(even NIT seems to be based on the Stanford packet filter), but
that base did not support promiscuous mode, and all those evolved
versions do.

Admittedly, it becomes a little trickier if your application does
fancy filtering, since the filter languages are slightly different
(the BPF language is entirely different).  However, most statistical
network monitors (as opposed to a trace-program such as tcpdump)
general want to see all (or almost all) the packets, so filtering
isn't an issue.

-Jeff

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 03:19:34 GMT
From:      dd26+@andrew.cmu.edu (Douglas F. DeJulio)
To:        comp.protocols.tcp-ip
Subject:   Re: Registered SMTP

mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) writes:
> In thinking about the issue some more, and reviewing people's worries
> about excess flurries of acknowledgements being generated by mailers
> along the line, it has occurred to me that the return message should
> not be part of SMTP but rather be part of the user's mail interface.

Two mail interfaces that currently provide this feature are the Andrew
Message System and NeXT Mail.  Both provide multimedia mail as well.
AMS is somewhat better IMHO (and I think it's free), but you need the
Andrew Tool Kit to get the multimedia features.
-- 
Doug DeJulio
ddj@zardoz.club.cc.cmu.edu (NeXT)
dd26+@andrew.cmu.edu (AMS/ATK)

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 04:14:39 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Testing if a host is up

In article <529@trux.UUCP> car@trux.UUCP (Chris Rende) writes:
>I need a way to put a test ahead of the FTP that will determine whether
>or not the other host is "up".
>Here is what I have so far:
 
># hostup - Written 01/30/91 by Chris Rende
[Script omitted]

Except for the exact text of the message printed, the ping command does
exactly what your shell script does.  It returns 0 status if the host is
up, and non-zero when the host is down.

This is on SunOS 4.0.3.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 06:42:29 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Testing if a host is up

In article <529@trux.UUCP> car@trux.UUCP (Chris Rende) writes:

   I have a shell script which does a FTP of a file over to another host.

   I need a way to put a test ahead of the FTP that will determine whether
   or not the other host is "up".

Just an observation -- just because a host answers pings doesn't
necessarily mean it's up.  Consider that it might be in single user
mode doing backups, with the network interface up but no inetd
services running and the partition you want to FTP to unmounted.

Not to say that noticing that a few pings don't come back isn't a good
idea, but it's not sufficient to guarantee service availability.
Depending on your application, it might be enough.

--Ed

-- 
 Msen	Edward Vielmetti
/|---	moderator, comp.archives
	emv@msen.com

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 06:56:28 GMT
From:      enag@IFI.UIO.NO (Erik Naggum, the Internet Purist)
To:        comp.protocols.tcp-ip
Subject:   Re: Registered SMTP

In article <9102141624.AA01275@telesys.ncsc.navy.mil>, Mark L. Williams writes:

> I dropped off a couple of messages supporting a "return receipt"
> registration feature for SMTP a while ago.  In thinking about the
> issue some more, and reviewing people's worries about excess
> flurries of acknowledgements being generated by mailers along the
> line, it has occurred to me that the return message should not be
> part of SMTP but rather be part of the user's mail interface.  The
> only thing that SMTP should support is some sort of header line that
> the mail application can use to determine whether or not a return
> message should be sent when the user displays (ok, we can't tell
> whether it's actually READ or not) the received message.  I think
> this approach is more logical; SMTP almost certainly should not get
> involved in sending "I got it" messages anywhere on its own.

Mark,

SMTP is a protocol.  Simple Mail Transfer Protocol.  It's not a piece
of software.  It can't do anything on its own.  Neither, might I add,
has there ever been any discussion of adding some feature to SMTP to
make it do anything differently.

You seem to ignore the problems that relate to the semantics of a
return receipt, and that this semantics is not supported by the
network technology (model) involved.

For instance, the "excess acknowledgements" is a real problem, not
because you implement it at some layer N, but because ACKs may not get
to their intended recipient.  That has nothing whatsoever to do with
which layer or which program or whatever actually does the ACK'ing.

--
[Erik Naggum]					     <enag@ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik@naggum.uu.no>

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 07:56:05 GMT
From:      VANCE@TGV.COM (Icarus)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS on VAX and TCP/IP on OS/2?

>    This is *damn* embarassing, but I just got a request for information
>regarding the availability of DNS server software on VAXen -- I *know* I saw
>something about this within the last couple of days, but since I wasn't
>interested in the topic at the time (I thought we had solved all of our DNS
>problems), I didn't keep a copy of the information.
>
>    Could someone refresh my memory as to what is available on VAXen for DNS
>server software?  Mind you, it will have to interoperate with Suns (3, 4, &
>386i) running various versions of the OS (4.0.1 through 4.1.1), and PCs running
>3Com Ether+ software & (probably) cc:mail (hmmm... Kind of sounds like we need
>to start our own mailing list for those of us that have VAXen, Suns, and PCs
>with cc:mail and having to make them interact -- Let me know what you think of
>this idea), etc....

I'm assuming from your comments later in the message that you mean VAXen
running VMS.  Several IP for VMS vendors ship with ports of the 4.3 BSD
BIND DNS server, including:

	Company			Product
	-------			-------
	TGV			MultiNet
	Wollongong		WIN/TCP
	Network Research	Fusion
	CMU			CMU/Tek

I think that CMU/Tek either now has or soon will have (Bruce, am I lying?) a
BIND server.  I know the others do.  If you need contacts at any of the above,
I can forward them to you.

I think that you'll find that most of the vendors who have ported BIND will
state that they are "bug-compatible" with the 4.3 BSD UNIX version.  This
should make the versions interoperate with any other implementation that
is bug-compatible.

Regards,
-----Stuart

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 10:18:48 GMT
From:      etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.tcp-ip
Subject:   Free Ethernet Snooper !!!

Hi,
 
We, at the Technical University Delft in the Netherlands have developed 
an ethernet snooper NetCapt. You can get is free with anonymous FTP from:

	dutepp0.et.tudelft.nl

in

	pub/NetCapt

Documentation is very sparce, but you can ask questions to

	JPMvOorschot@et.tudelft.nl

We're developing a new version with SNMP support. If anyone wants to 
be beta-site, let me know.

Greetings    Jan

JPMvOorschot@et.tudelft.nl

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 11:22:08 GMT
From:      basien@pemcom.pem-stuttgart.de (Tillman Basien)
To:        comp.unix.questions,comp.unix.msdos,comp.protocols.nfs,comp.protocols.tcp-ip,comp.unix.xenix.sco,comp.unix.sysv386
Subject:   Is the a Source of a DOS-Telnet



I want to write my own telnet under PC-NFS, because I need a PC-TERM-Emulation.
There a severel steps:
	What must I do in C to get a TCP/IP connection under PC-NFS to my
	hosts?
	Does anybody has an example software ?


Thanks for every response
Tillmann	

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      16 Feb 91 12:06:05 GMT
From:      doug@goodall.UUCP (Douglas Wade Goodall)
To:        comp.protocols.tcp-ip
Subject:   (none)

Regarding Token Ring for VME Bus
In the latest VMEbus Systems magazine, two vendors were
mentioned, INTERPHASE with their V/TOKEN-RING 4212OWL and
SBE with their Model VCOM-33 ( 415-680-7722)
Good Luck.  Regards from Petaluma, California.

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 91 03:42:15 GMT
From:      jgd@Dixie.Com (John G. DeArmond)
To:        comp.protocols.tcp-ip
Subject:   Re: Free Ethernet Snooper !!!

etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot) writes:

>an ethernet snooper NetCapt. You can get is free with anonymous FTP from:
>	dutepp0.et.tudelft.nl
>in
>	pub/NetCapt

Hi Jan, 

Thanks for the software.  It is ftp'ing even as I type. One small correction.
I found the file in /pub/NetCure/NetCapt.zip.  This will make it a bit
easier for those who have to use ftp servers.

John


-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it  

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 91 04:39:14 GMT
From:      vijay@nixdorf2.osf.org (Vijay Kumar)
To:        comp.protocols.tcp-ip
Subject:   Thinnet, Thicknet

Hi,

Can someone tell me the difference between Thinnet and Thicknet.
I would also like to know the advantages and disadvantages of one
against another.

Thanks in advance.

Vijay

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 91 10:30:02 GMT
From:      etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.tcp-ip
Subject:   NetCure, Free Ethernet Snooper, more

Hi,

I have quit a few reactions on my posting about our free Ethernet Snooper
developed at the Technical University Delft in the Netherlands. My first 
posting did have some bugs in it, so here i go again:

	NetCure is a PC based ethernet snooper that reports about traffic,
	packet distributions, packet-types, and a top-ten list of hosts.
	FurtherMore, it has a seperate packet dumper plus a packet
	displayer with a protocol formatter.

	The NetCure package uses packet-device drivers to handle 
	the network hardware, so you will need a packet-driver
	for your ethernet card !

	After loading your packet driver, you can run one of the
	network components NetMon (monitoring), NetCapt (dumping),
	and NetView (packet viewing).

	The package is full-screen, with lots of fancy windows, but
	the documentation is lacking, so hackers-only !

	You can get the package from

		dutepp0.et.tudelft.nl

	with anonymous ftp, it is in the directory

		NetCure

	and consists of a number of ".zip" files:


		ReadMe			: very sparce docu
		netcapt.zip		: dumping and viewing	
		netmon.zip		: monitoring	
		pkt7com.zip		: packet driver distribution,
					: just to be complete !

	Unpack the files netcapt.zip and netmon.zip in one 
	directory, load your packet-driver and run netmon.exe.
	The rest should be clear   (;-) )

Jan

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 91 12:53:07 GMT
From:      VERKADE@CTSS.CO.UK (Herman Verkade)
To:        comp.unix.misc,comp.protocols.tcp-ip,comp.windows.x
Subject:   Advise needed

I am thinking of changing my old IBM-clone to a Unix machine, since I never use
it with it's current MS-DOS. It's a 286 system with a Herculus-compatible
graphics card, 640K main memory and an 80Mb Seagate hard disk. I would like to
run some form of Unix, TCP/IP over Ethernet and SLIP, X windows, GCC, GC++ and
news. Could some kind people answer one or more of the following questions:

1) What Unix should I go for?
2) What sort of Ethernet board should I go for?
3) Can I run X windows on the Hercules board? (If not I'll only use it as a
   client).
4) If TCP/IP doesn't come with the Unix, where do I get it from?
5) Do I need more memory?
6) Is the machine actually up to anything of the above?

Please, reply by e-mail.

Thanks in advance

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 91 13:09:37 GMT
From:      tkevans@fallst.UUCP (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Testing if a host is up

In <EMV.91Feb16014229@poe.aa.ox.com> emv@ox.com (Ed Vielmetti) writes:

>In article <529@trux.UUCP> car@trux.UUCP (Chris Rende) writes:
 
>   I need a way to put a test ahead of the FTP that will determine whether
>   or not the other host is "up".
 
>Just an observation -- just because a host answers pings doesn't
>necessarily mean it's up.

Assuming you have appropriate /etc/hosts.equiv and/or .rhosts set up,
you could 'rsh' something like /bin/echo on the remote:

	if rsh remote [ -l user ] /bin/echo > /dev/null
	then whatever
	fi
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 91 16:32:37 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over X25

From article <1991Feb15.235715.21152@Think.COM>, by barmar@think.com (Barry Margolin):
- SunLink X.25 implements RFC877 for SunOS.  The manual mentions one minor
- difference between its implementation and the RFC, though.  Rather than
- creating and clearing X.25 virtual circuits dynamically, they must be
- created and cleared explicitly by using the x25enable and x25disable
- commands.
- 
->What is the maximum speed that is supported by such a product ? Most
->kernels donot support very high speeds. Ultrix for instance does not
->allow 19Kb or higher. Sun and HP do allow 19Kb transfer rates !
- 
- According to the manual, 19.2Kbps is the maximum speed using the CPU board
- serial ports, but you can go up to 64Kbps using an MCP or SCP.

Real life experience: Sun3/50: 9.6kbps, Sun3/xx(other than 3/50): 19.2kbps,
Sun4/xxx: 64kbps - all over CPU ports. MCP ports 64kbps each, HSI 2Mbps.

The timing for asynchronuous operation is normally irrelevant for
HDLC, as the clock will normally be generated by the modem. Even if generated
by the Sun itself, the timing does not depend on the usual baud rate
table for the asynchronuous interfaces, so it's no problem running the
interfaces at higher speeds. The real problem is overrun, as all the
CPU board serial interfaces generate one interrupt for every 'character'
(i.e: 8 bit), so that's why a 3/50 can only achieve 9.600kbps. If you
try something higher, you'll get massive problems with HDLC RESETS, as
the interface looses interrupts and the HDLC link will constantly
reset.

On the other hand, the MCP board is (in my opinion) quite useless as 
the guaranteed linkrate is only 64kbps, which you can aesily achieve
with the CPU ports of every sparc (except those cripled IPC's, if you
don't start soldering on the CPU board for the clock lines ;-)).

---

             Toerless.Eckert@informatik.uni-erlangen.de
    /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless
"unsupported configuration", "user misunderstanding", "not a bug, but a feature"
                   -- hotlines of the world unite --

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      17 Feb 91 22:50:49 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Testing if a host is up

In article <1917@fallst.UUCP> tkevans@fallst.UUCP (Tim Evans) writes:
> Assuming you have appropriate /etc/hosts.equiv and/or .rhosts set up,
> you could 'rsh' something like /bin/echo on the remote:

That still wouldn't prove that ftp is available.

What's wrong with simply connecting to the service in question and
seeing whether it responds?

---Dan

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 09:15:53 GMT
From:      njl5453@tesla.njit.edu
To:        comp.protocols.tcp-ip
Subject:   ===>> Seeking help with MICROCONTROLLERS...................




	any body familiar with MICROCONTROLLERS.

	following:	Motorola MC68HC11
			Intel	386

	also,	available LCDs.

	if yes, i need info on its operations
	and cost, etc...

	please give me your e-mail address at:

		nitin@mars.njit.edu

	i am undergrad senior at New Jersey Institute of Technology
	Newark, NJ.
	I am working on Senior project which requires 
	designing of device using the Single Chip Computers.
	Thank you in advance..
	-nitin

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 12:48:15 GMT
From:      martin@vd.volvo.se (Martin B|rjesson)
To:        comp.protocols.tcp-ip
Subject:   Commercial 3270 emulator??


I'm looking for good 3270 (i.e. 3179 or someting similar) emulators, for 
use with Suns, HPs, RS/6000 and Decstations in one end and IBM's TCP/IP 
running on the MVS end. GDDM and color support is a must. We prefer commercial 
products.

Thanks in advance!

/martin 


-- 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Martin Borjesson,     |Snail Mail:         |E-mail: martin@[cae.]volvo.se
Volvo Data            |405 08, Goteborg    |Phone: (46) 31 667182 (work)
Dept 2610, Geogr: DLI |Sweden              |       (46) 31 233409 (home)

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 14:35:20 GMT
From:      dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

Erik Naggum raises a host of interesting points in his comparison of email to
the postal service's registered/certified mail.  I tend to support his 
conclusion that "registered" email will be a long time comming, but for 
social, rather than technical reasons.

While I'm not a lawyer, my understanding of the legal status of email is that
it does not have any of the protections accorded to paper (Post Office) mail.
While it is a crime for the post office to tamper with your letters, there
appears to be nothing preventing any mail relay from reading/modifying/deleting
your mail at will.  A recent case against Epson America, where an employee was
fired (and frogmarched out of the building by the police, no less!) for
objecting to Epson's policy of reading employee's email, was dismissed because
it Epson has not violated either the Electronic Communications Privacy Act
or California wiretaping statutes.  The judge ruled flat out that wiretaping
does not apply to email.  (Note that a similar suit has been files against
Nissan USA).

So what does this mean (rather than don't buy Epson or Nissan products)?
Email appears to have absolutely no legal protections, or any standing in a
court of law (don't tell me about Ollie North - that was no court, that was
the congress).  I would suggest that email providers will not venture into
this field until the LEGAL status of email is established.  Imagine the 
liability of (for example) MCI if they offer a "Certified" email that can be
manhandled by any system administrator on the net ...

This may be a case of a solvable (eventually) *technical* problem but an
insoluable social one.

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

"The first thing we do, it to kill all the lawyers." -Wm. Shakespeare

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 15:24:31 GMT
From:      markm@nddsun1.sps.mot.com (Mark Monninger)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Tandem 6530 terminal emulator (tn6530?)

In article <1991Feb14.170436.7587@tandem.com> kevinr@Tandem.COM writes:
>In article <626@deere.com>, paulf@deere.com (Paul A. Fisher) writes:
>|> 
>|> We are looking for a product similar to tn3270, except it emulates a Tandem 
>|> 6530 terminal instead of an IBM 3270 terminal.  We now have TCP/IP running on 
>|> We have heard that this product does exist, but so far we have found no leads.
>
>One exists. It's called TN6530. It comes with the TCP/IP S/W you order from
>Tandem.
>
>kevinr@tandem.com

That's true, but it's only the server. The original release included a
TN6530 client for the Sun workstation. How about a TN6530 client for
DOS machines? Seems like that would be a helluva lot more useful to most
people than a Sun version, esp. since the PC's with Tandem's name on 
them are DOS machines. I understand that there are TN6530 clients for
Mac's and even an X-Windows version but so far I haven't heard of a DOS
version. If anyone knows of one, please let me know.

Mark

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 15:26:51 GMT
From:      dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty)
To:        comp.protocols.tcp-ip
Subject:   Re:  Compressed Video Transport Requirements

I think that there are two problems with *REAL TIME* video: variation of
delay and synchronization.  If the delay between packets varries too much,
the picture would jump (like the strobe lights at your old disco parties)
like crazy, causing Excedrin headache #423.  if you have synchronization
problems (voice and video arriving out of sync), it looks like a badly
dubbed movie (remember the Hercules skitt on Saturday Night Live?).  Either
way you irritate the users.

Note that ethernet doesn't look good for problem #1.  Maybe nothing is (FDDI
II?  Now how much would you pay ...).

I think these problems are not so severe if you're not going real-time.

I don't have references about video, but I do have some performance modeling
results of FDDI synchronous token stuff.  Send me your U.S. Postal address if
you want 'em (I only have hard copy).

- Ted

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

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 15:41:52 GMT
From:      dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty)
To:        comp.protocols.tcp-ip
Subject:   (none)


Erik Naggum raises a host of interesting points in his comparison of email to
the postal service's registered/certified mail.  I tend to support his 
conclusion that "registered" email will be a long time comming, but for 
social, rather than technical reasons.

While I'm not a lawyer, my understanding of the legal status of email is that
it does not have any of the protections accorded to paper (Post Office) mail.
While it is a crime for the post office to tamper with your letters, there
appears to be nothing preventing any mail relay from reading/modifying/deleting
your mail at will.  A recent case against Epson America, where an employee was
fired (and frogmarched out of the building by the police, no less!) for
objecting to Epson's policy of reading employee's email, was dismissed because
it Epson has not violated either the Electronic Communications Privacy Act
or California wiretaping statutes.  The judge ruled flat out that wiretaping
does not apply to email.  (Note that a similar suit has been files against
Nissan USA).

So what does this mean (rather than don't buy Epson or Nissan products)?
Email appears to have absolutely no legal protections, or any standing in a
court of law (don't tell me about Ollie North - that was no court, that was
the congress).  I would suggest that email providers will not venture into
this field until the LEGAL status of email is established.  Imagine the 
liability of (for example) MCI if they offer a "Certified" email that can be
manhandled by any system administrator on the net ...

This may be a case of a solvable (eventually) *technical* problem but an
insoluable social one.

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

"The first thing we do, it to kill all the lawyers." -Wm. Shakespeare

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 15:47:32 GMT
From:      dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty)
To:        comp.protocols.tcp-ip
Subject:   (none)

well!bnox%well.sf.ca.us@apple.com posted a message about problems with
TCP configuration on a PC running SCO.  I tried responding to him only,
but the mailer barfed on the address.  So here it is (sorry for
cluttering the ether ...):

Your problem is in the mkdev tcp statement.  The Internet Address is *NOT* the
same as the address printed on the ethernet card (in short, Xerox is the keeper
of the sacred ethernet address space - if you want to sell ethernet stuff, you
buy a block of addresses from them; however, you can assign your own IP
addresses at will (unless you are connecting tothe Internet)).

Fortunately, the solution looks pretty easy - use an IP address like :

                      192.1.164.<host number>

where <host number> is a one-byte address that is not duplicated by any other
host on that net.  Note that *ALL* hosts on that net will have an address of
the form 192.1.164.<something>

There is this magic thing called ARP that takes care of mapping IP addresses
to ethernet addresses, so don't worry about it.

Things should work after this.  OBTW, if you are new to the wonderful world
of TCP/IP, run don't walk to your nearest technical bookstore and score
yourself a copy of "Internetworking with TCP/IP" by Douglas Comer (2nd Ed.)
(Prentice-Hall, 1990, ISBN 0-13-468505-9).  While you'll find that you outgrow
it pretty quickly, it's the best introduction it TCP/IP that I've seen.

- Ted Doty, Network Systems Corporation  phone: +1 301-596-2270

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 16:39:52 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   SLIP with an ANNEX

The Annex terminal servers run SLIP (and soon CSLIP), but employ a scheme
where the remote and local IP address for each port have to be preset.

This means on the remote SLIP node (a Sun in my case), the local side of
the SLIP interface will vary and in no way identify the workstation. Also
in my case the SLIP is the only local interface other than the loopback.

Does anyone see a way for me to assign a permanent IP address to the 
workstation, and have the connections from the workstation appear to
come from that address, not the variable Annex chosen address. Unless
I'm missing something, this is exactly what would happen if I had a second
remote workstation connected by ethernet to the first, and routing
through it accross the SLIP link.

Frankly, the Annex scheme seems a bit out of date. The host based SLIPs
seem to handle this with a sliplogin program that can set the IP address
of the SLIP link from an id keyed database. Its a little surprising that
Xylogics hasn't done something like this, they do have host based support
for other data.



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

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 17:19:30 GMT
From:      JAFFE@SSCVX1.SSC.GOV
To:        comp.protocols.tcp-ip
Subject:   Modify Subscription


Please change my subscription address to jaffe@sscvx1.ssc.gov.  Thanks

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 18:24:16 GMT
From:      pww@bnr.ca (Peter Whittaker)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified SMTP mail

In article <9102181435.AA05874@nscultrix1.network.com> dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) writes:
>While I'm not a lawyer, my understanding of the legal status of email is that
>it does not have any of the protections accorded to paper (Post Office) mail.
>
>This may be a case of a solvable (eventually) *technical* problem but an
>insoluable social one.


One solution is to send only encrypted mail, preferably something encrypted
using the intended recipient's public key:  the recipient is therefore the
only person who can decrypt it.  (For more information, check out articles
or books on Privacy Enhanced Mail (PEM) or Public Key CryptoSystems (PKCS).
See also CCITT X.509).  The solution ends up being technical rather than
social.:->

Of course, an employer might disallow encrypted mail on corporate systems....



--
Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww@bnr.ca           [                          ]   Bell Northern Research 
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 18:39:09 GMT
From:      shaikh@image.soe.clarkson.edu (Asad Shaikh)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP using Phil Karan code

I am using Phil Karan code and designing a protocol for data transfer.
my problem is rece_mbuf is working more than once.


Client					Server

send_mbuf				recv_mbuf
recv_mbuf				send_mbuf
send_mbuf				recv_mbuf(Not working).


recv_mbuf is sitting and  can not get out from loop
I mean from pawit(). My question is can some one use recv_mbuf more
than once. 

Thanks

asad

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 19:27:21 GMT
From:      uccxmgm@unx2.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   DOS-Based Name Server


     I hear that there is a DOS-based domain name server
produced by a company called "FTP Software."  If anybody has
experience with it, please reply to
u1906ad@unx.ucc.okstate.edu
     Thanks.

Martin McCormick
WB5AGZ
Oklahoma State University
Stillwater, Oklahoma 74078
405-744-6301

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 19:32:58 GMT
From:      tr@samadams.princeton.edu (Tom Reingold)
To:        comp.protocols.tcp-ip
Subject:   load average for System V

In Wollongong's tcp/ip package for System V, you get rwhod and
ruptime.  So apparently, they know how to compute load average.  Now,
I'd like to compute it too, in the hope that I can dispose of the use
of rwhod.  How is it computed?  I find it odd that uptime is not
included while ruptime is.
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
        from windshield before starting ignition."

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 21:57:04 GMT
From:      hgv@daphne.network.com (Harry G. Varnis)
To:        comp.protocols.tcp-ip
Subject:   Requirements for Hosts and BSD


Could someone point me to a statement of conformance to RFC1122/1123
for the BSD-tahoe TCP/IP stack, please?
-- 
Harry Varnis         <hgv@anubis.network.com>          (612) 424-4888

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      18 Feb 91 23:27:44 GMT
From:      woods@ncar.ucar.edu (Greg Woods)
To:        comp.protocols.tcp-ip
Subject:   Re: third-party traceroute

In article <9102152346.AA04371@ganges.ucop.edu> spgdrp@GANGES.UCOP.EDU writes:
>There is a public domain version of traceroute posted on zerkalo.harvard.edu.
>I don't know if this is the canonical source.
>You should know that this program requires modifying your kernel.

  I found it on ftp.cc.berkeley.edu. Whether or not it requires kernel mods
depends on what OS you are running. We run SunOS 4.1 here and I was able
to compile and run third party traceroute without any kernel mods. Thanks
to all who responded.

--Greg

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 02:19:00 GMT
From:      Sabo@DOCKMASTER.NCSC.MIL
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP comparison

>>Yes, Datapro has completed a study of SNMP-based management stations
and >>will soon release a report on SNMP-based agent.  The SNMP manager
report >>is often given away free of charge.  Contact Jill
Huntington-Lee at >>(800) DATAPRO ex 2444.  >> > >A non-800 number or
E-mail address would be nice for non US sites.  > >Erick > MCIMAIL.COM

L.  Michael Sabo

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 03:09:04 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  Certified SMTP mail

> The postal service is paid to deliver your mail.  When you buy the
> service of registered mail, the postal service is required by law to
> deliver it and record the delivery in a way which you can rely on,
> legally.  You can request return receipts from the postal service as
> well, and the postal service has a big problem if you don't get a
> return receipt when the letter was received.  There is no one who can
> assume this responsibility in the Internet.  Thus, the "shortcoming"
> stems from the nature of the service provider involved, and SMTP
> reflects this.

At least in the US there is something called certified mail, which is
less stringent than registered mail.  It does not guarantee that the
letter will arrive, but simply keeps a record if it does.  You can also
request a return receipt, which can also get lost along the way back.
Even with registered mail, there is no assurance that the return
receipt will make it back to you.  Only the original letter is
safeguarded while enroute.  There is no such safeguarding for certified
mail.

We have email acknowledgements on some of our internal systems.  They
aren't used extensively, so the extra traffic is minimal.  The normal
reason for using them is to get some reasonable assurance that the
message did make it to the addressee.  The idea is to follow up if the
acknowledgement is not received in a reasonable time.  I don't think
that anyone believes that it is legally binding in any way.  Regardless
of what you think of acknowledgements, they are a feature that many
people want.

This discussion more properly belongs on the header-people list.  Also,
there is now an IETF working group considering enhancements to RFCs 821
and 822.

Roger Fajman                                   Telephone:  +1 301 402 1246
National Institutes of Health                  BITNET:     RAF@NIHCU
Bethesda, Maryland, USA                        Internet:   RAF@CU.NIH.GOV

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 10:22:34 GMT
From:      nanchen@uni2a.unige.ch
To:        comp.protocols.tcp-ip
Subject:   TCP/IP <--> IBM network (link?)

Hello!

I've just a simple question: a friend of mine, who's working at IBM and uses
the IBM-network, wonders if there is a way for him to access this network we are
all using directly from his IBM-terminal (he's working in under VM/CMS and
MVS/TSO-E and uses IBMtype adresses: NAME at NODE)? How, if the physical link
between the two networks actually exists, should he write the adresses to be 
understood by TCP/IP?

Does anybody know anything about this?

Joel (MARGOT@eldp.epfl.ch - I'm using a friend's account for posting this
letter).

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 12:47:37 GMT
From:      ms@pe.dk (Mogens Soerensen)
To:        comp.protocols.tcp-ip
Subject:   Is there a protocol for remote printing ?


Does a standard protocol exist for remote printing on tcp/ip ? I have
been looking in RFC's and in different litterature for a specification,
but haven't found one. 
     
I am also interested in specifications for the protocol used by the BSD
lpd daemon, and if such a protocol exists for SYSV also the protocol
used by the lpsched.

Please email any pointers or protocol specifications, I will post a
summary if there are interest.

Thanks in advance.

+--------------------------------+---------------------------------+
|  Purup Electronics a/s         |  Email: ms@pe.dk                |
|  Att: Mogens Soerensen, R&D    |  Uucp.: ...!mcsun!dkuug!pe!ms   |
|  Sonderskovvej 5               |  Phone: +45 8622 2522           |
|  DK-8520 Lystrup               |  Fax..: +45 8622 2511           |
|  DENMARK                       |  Telex: 68242 purel dk          |
 +--------------------------------+---------------------------------+

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 13:43:42 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams)
To:        comp.protocols.tcp-ip
Subject:   Re:  DNS on VAX and TCP/IP on OS/2?

Brad Knowles asks...

> Could someone refresh my memory as to what is available on VAXen for DNS
> server software?

Don't know for sure offhand, but it seems like our Wollongong stuff uses
DNS on VAXen.

> Kind of sounds like we need to start our own mailing list for those
> of us that have VAXen, Suns, and PCs with cc:mail and having to
> make them interact -- Let me know what you think of this idea

I'd like to know more about cc:mail capabilities in the environment you
describe...

> BTW, does anyone know of a full suite of TCP/IP applications written to run
> on OS/2 (with the 3Com Ethernet software)?

3Com's 3+Open TCP/IP includes an OS/2 version as well as a DOS version.

Mark

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 15:14:50 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  PPP Documentation wanted


 > From tcp-ip-RELAY@NIC.DDN.MIL Fri Feb 15 23:14:40 1991
 > From: swrinde!cs.utexas.edu!sdd.hp.com!samsung!munnari.oz.au!uniwa!vax7!nmurrayr@ucsd.edu  (Ron Murray)
 > Organization: Curtin University of Technology
 > Subject: PPP Documentation wanted
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > 
 >    I'd like to get the specs for PPP. RFC number (if any) or other help
 > would be appreciated.
 > Thanks,
 > ....Ron
 > 
 > -- 
 > 
 > ===============================================================================
 >  Internet: Murray_RJ@cc.curtin.edu.au                | "You can lead a horse to
 >  ACSnet: Murray_RJ@cc.cut.oz.au                      | water, but if you can
 >  Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet    | get him to float on his
 >  UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
 > Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
 >                TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
 > ===============================================================================
 > 

From the latest rfc-index.txt (available at most RFC repositories):

1172  Perkins, D.; Hobby, R.  Point-to-Point Protocol (PPP) initial
      configuration options.  1990 July; 38 p. (Format: TXT=76132 bytes)

1171  Perkins, D.  Point-to-Point Protocol for the transmission of
      multi-protocol datagrams over Point-to-Point links.  1990 July; 48 p.
      (Format: TXT=92321 bytes)  (Obsoletes RFC 1134)

There are also a couple of internet drafts which may be of interest:

	draft-ietf-ppp-multidatagrams-02.txt
	draft-ietf-ppp-options-03.txt
	draft-ietf-ppp-pppmib-00.txt
	draft-ietf-ppp-pppmib-01.txt
	draft-ietf-pppext-bridging-00
	draft-ietf-pppext-pppmib-00.txt
	draft-ietf-pppext-pppmib-01.txt

Frank Kastenholz
Clearpoint Research

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 16:43:14 GMT
From:      us267388@mmc.mmmg.com (Bradley D. Rhoades)
To:        comp.protocols.tcp-ip
Subject:   RFC 931 - Authentication Server?


	Recently an rfc931 implementation of an authentication server was
	made available.  I understand the basics of the protocol after
	reading the RFC and author notes, but I am curious why I should use
	it now.  Do any utilities available today utilize the authentication
	server?  What good does it do for me to run it now?


-- 
Bradley D. Rhoades	          E/Mail: bdrhoades@mmc.mmmg.com
3M, 2465 Lexington Ave So         NIC: BR79
Building 60-1N-01                 WRK: +1 (612) 736 2874
Mendota Heights, MN  55120        FAX: +1 (612) 736-0431

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 16:53:16 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Whose source route wins in TCP connections?


            "When a TCP connection is OPENed passively and a packet 
            arrives with a completed IP Source Route option (containing 
            a return route), TCP MUST save the return route and use it 
            for all segments sent on this connection..."
    
    Ok, fine.  But does this mean the passive end of the connection cannot 
    issue a source route of its own?  Note that the preceding paragraph of 
    the RFC says 
    
            "An application MUST be able to specify a source route when 
            it actively opens a TCP connection, and this MUST take
            precedence over a source route received in a datagram."
    
    Where did this received source route come from if the passive end
    has to save a received return route (presumably received from the 
    actively opened end) and 'use it for ALL segments sent on this 
    connection' ?
    
At the passive end, the active's source route is known to work (it got the
packet there, after all), and so the incoming source route should override
anything the application specified.  If the active end got a response,
their initial route worked, and they should ignore anything that comes
back, in case some really quirky asymmetric routing situation required
that humans intervene on the passive side to make it work...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 17:22:48 GMT
From:      uccxmgm@unx2.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   IBM3270-VT100 Emulator


     Our data communications operation is looking for a TCP-
IP based IBM3270 to VT-100 protocol converter capable of
handling at least 64 terminal sessions.  We are looking for
something much like the Mitek product only hopefully less
expensive.  The device should be channel-attached on the IBM
side and communicate over Ethernet on the TCP-IP side.  Our
present IBM3270 emulators are part of our asynchronous
network and appear to the IBM side of the connection as
remote controllers.  Any information, either good or bad
about IBM3270 emulators you have known would be appreciated.
Please Email to 
u1906ad@unx.ucc.okstate.edu


Many thanks.

Martin McCormick
Data Communications Group
Oklahoma State University
Stillwater, Oklahoma 74078

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 19:01:04 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Whose source route wins in TCP connections?


	    
	At the passive end, the active's source route is known to work (it got the
	packet there, after all), and so the incoming source route should override
	anything the application specified.  If the active end got a response,
	their initial route worked, and they should ignore anything that comes
	back, in case some really quirky asymmetric routing situation required
	that humans intervene on the passive side to make it work...

	James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
	FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

Thanks, James, as always you said it better than I did!

Bob

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 19:48:23 GMT
From:      griff@Xylogics.COM (Scott Griffiths)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP with an ANNEX

In article <1991Feb18.113952@mathcs.emory.edu> km@mathcs.emory.edu (Ken Mandelberg) writes:
>The Annex terminal servers run SLIP (and soon CSLIP), but employ a scheme
>where the remote and local IP address for each port have to be preset.
>
>This means on the remote SLIP node (a Sun in my case), the local side of
>the SLIP interface will vary and in no way identify the workstation. Also
>in my case the SLIP is the only local interface other than the loopback.
>

--- deleted --

>
>Frankly, the Annex scheme seems a bit out of date. The host based SLIPs
>seem to handle this with a sliplogin program that can set the IP address
>of the SLIP link from an id keyed database. Its a little surprising that
>Xylogics hasn't done something like this, they do have host based support
>for other data.
>
Xylogics has available an unsupported version of our erpcd program which
supports dial-up slip as you request. You supply a simple user lookup
routine. After identifying the user to the annex security subsystem, the
incoming port is re-configured as a slip port with the user matched IP
address. Upon modem hangup, the port is configured back to  CLI mode.
This code is ftp-able via anonymous ftp to xylogics.com in 

~ftp/annex/unsupported/acp
 
or by requesting it via email to annex-support@xylogics.com.

Scott Griffiths					phone: (617) 272-8140 x332
Xylogics Annex Technical Support		email: griff@xylogics.com
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SLIP with an ANNEX
Summary: 
Expires: 
References: <1991Feb18.113952@mathcs.emory.edu>
Sender: 
Reply-To: griff@Xylogics.COM (Scott Griffiths)
Followup-To: 
Distribution: 
Organization: Xylogics, Inc., Burlington MA
Keywords: 

In article <1991Feb18.113952@mathcs.emory.edu> km@mathcs.emory.edu (Ken Mandelberg) writes:
>The Annex terminal servers run SLIP (and soon CSLIP), but employ a scheme
>where the remote and local IP address for each port have to be preset.
>
>This means on the remote SLIP node (a Sun in my case), the local side of
>the SLIP interface will vary and in no way identify the workstation. Also
>in my case the SLIP is the only local interface other than the loopback.
>
>Does anyone see a way for me to assign a permanent IP address to the 
>workstation, and have the connections from the workstation appear to
>come from that address, not the variable Annex chosen address. Unless
>I'm missing something, this is exactly what would happen if I had a second
>remote workstation connected by ethernet to the first, and routing
>through it accross the SLIP link.
>
>Frankly, the Annex scheme seems a bit out of date. The host based SLIPs
>seem to handle this with a sliplogin program that can set the IP address
>of the SLIP link from an id keyed database. Its a little surprising that
>Xylogics hasn't done something like this, they do have host based support
>for other data.
>

Xylogics has available an unsupported version of our erpcd program which
supports dial-up slip as you request. You supply a simple user lookup
routine. After identifying the user to the annex security subsystem, the
incoming port is re-configured as a slip port with the user matched IP
address. Upon modem hangup, the port is configured back to  CLI mode.
This code is ftp-able via anonymous ftp to xylogics.com in 

~ftp/annex/unsupported/acp
 
or by requesting it via email to annex-support@xylogics.com.

Scott Griffiths					phone: (617) 272-8140 x332
Xylogics Annex Technical Support		email: griff@xylogics.com

-- 

Scott Griffiths					phone: (617) 272-8140
Xylogics Annex Technical Support		email: griff@xylogics.com

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 20:15:38 GMT
From:      cml8@robin.cs.uofs.edu (Chris M. Little)
To:        comp.mail.misc,comp.mail.elm,comp.protocols.tcp-ip
Subject:   How to receive mail on all stations in our Sun network. ???

We have a network of about 12 Sun SPARCstations.  I can log in to any station
and be in my home directory.  I guess we have a single fileserver fo all the
stations.  However, is someone sends me mail to on station, I can only read it
on that station.  Is there any way that I could be notified of new mail on any
station in the network and also read the new mail on any station?

E-mail responses would be appreciated.  Thanks.



-- 
Chris Little, Graduate Asstistant	-     CML8@JAGUAR.UOFS.EDU	(VMS)
Department of Computing Sciences	-     CML8@SCRANTON.BITNET	(VMS)
University of Scranton, Pennsylvania.	-     CML8@SPARROW.CS.UOFS.EDU  (UNIX)

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 20:48:24 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp


A bit of drift, but which routers support MINMTU (RFC 1191) at this
point?...

rick jones

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 22:01:53 GMT
From:      phil@shl.com (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   Re: Tandem 6530 terminal emulator (tn6530?)

In article <851@nddsun1.sps.mot.com> markm@nddsun1.sps.mot.com (Mark Monninger) writes:
>How about a TN6530 client for
>DOS machines? 

Failsafe Systems has one for DOS.  They can be reached at 708-390-6660.
They also sell an alternative to Tandem's TCP/IP.

I might be able to answer some more questions if you have any...

-- 
Phil Trubey
SHL Systemhouse Inc.
(Internet: phil@shl.com      UUCP: ...!uunet!shl!phil)

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 22:10:18 GMT
From:      ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: Testing if a host is up

In article <1991Feb16.041439.1038@Think.COM>, barmar@think.com (Barry
Margolin) writes:
> In article <529@trux.UUCP> car@trux.UUCP (Chris Rende) writes:
> >I need a way to put a test ahead of the FTP that will determine whether
> >or not the other host is "up".
> >Here is what I have so far:
 
> ># hostup - Written 01/30/91 by Chris Rende
> [Script omitted]
> 
> Except for the exact text of the message printed, the ping command does
> exactly what your shell script does.  It returns 0 status if the host is
> up, and non-zero when the host is down.
> 

Also, more as a heads up...  Some SLIP-ed or PPP-ed hosts have ICMP
messages filetered out specifically to prevent pings from clogging
low-speed links.  Although I don't necessarily agree with this, I do
see that the SLIP/PPP code allows this.

... Erik
---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 22:17:31 GMT
From:      jrr@lanl.gov (John R. Red-horse)
To:        comp.protocols.tcp-ip
Subject:   telnet and ftp for DEC's SysV UN*X

We are running a DEC version of System V (I believe it's r3) on a VAX
8540.  The version of ftp imposes a hard limit on file sizes somewhere
in the neighborhood of 1Mbyte.  I assume that this is a parameter that
can be changed, but I don't have the source to do the fix.  Does
anyone out there know where I might obtain such an animal?  Better
yet, how about a version that's already fixed?
Cheers,

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 23:09:01 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   SNA tunneling?

Is anyone working on a standard for IP tunneling over SNA networks?
That is, given an existing SNA network, and a desire to use it for IP
transport, is there an equivalent to any of RFCs 1201, 1188, 1171,
1149, 1088, 1042, and 877?

(OK, I just mentioned 1149 to see if you were really watching :-)

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      19 Feb 91 23:51:17 GMT
From:      meb@ee.mu.OZ.AU (Matthew Barry)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP using streams?


Can anyone tell me which operating systems have implementions of
TCP/IP using streams modules?


Thanks in advance,

	Matthew Barry

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 00:49:19 GMT
From:      zazula@uazhe0.physics.arizona.edu (RALPH ZAZULA)
To:        comp.protocols.tcp-ip
Subject:   Help needed getting KA9Q running on PC...

I'm trying to get a SLIP connection working from my PC.  I am
trying to use KA9 but the manual is giving me no help at all.
Does anyone out there use or know how to use this program?  IS
there a better program to use a SLIP connection?

Thanks,
Ralph

   |----------------------------------------------------------------------|
   | Ralph Zazula                               "Computer Addict!"        |
   | University of Arizona                 ---  Department of Physics     |
   |   UAZHEP::ZAZULA                            (DecNet/HEPNet)          |
   |   zazula@uazhe0.physics.arizona.edu         (Internet)               |
   |----------------------------------------------------------------------|
   |   "You can twist perceptions, reality won't budge."  - Neil Peart    |
   |----------------------------------------------------------------------|

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 00:56:05 GMT
From:      enger@SEKA.SCC.COM (Robert M. Enger)
To:        comp.protocols.tcp-ip
Subject:   RE: Third party traceroute (source-route traceroute)


The version of traceroute on Zerkalo.harvard.edu is a composite of
the various available sources and enhancements
(including source-route ability).  

IF THE VERSION OF TRACEROUTE ON ZERKALO IS  NOT  THE MOST COMPLETE,
I WOULD APPRECIATE IT IF SOMEONE WOULD SET US STRAIGHT.  THANKS!!

Also, some machines' operating systems no longer require
kernel modification to support traceroute.

Happy debugging,
Bob Enger

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 00:57:03 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Third party traceroute (source-route traceroute)

In article <9102200056.AA00350@seka.scc.com> enger@SEKA.SCC.COM (Robert M. Enger) writes:

   The version of traceroute on Zerkalo.harvard.edu is a composite of
   the various available sources and enhancements
   (including source-route ability).  

   IF THE VERSION OF TRACEROUTE ON ZERKALO IS  NOT  THE MOST COMPLETE,
   I WOULD APPRECIATE IT IF SOMEONE WOULD SET US STRAIGHT.  THANKS!!

As far as I know, the traceroute package on zerkalo and the 4.3
bsd-reno traceroute on (e.g.) wuarchive.wustl.edu are the latest of
the publically available traceroute implementations for BSD Unix.

There is no way to know what all else other people might have hacked
into the code, in their own effort to make it complete.  If someone has
done this they haven't spoken up.

By the way, how's the "noctool2" group's efforts coming along?  Send
me some mail (if you can read my mangled address), I have some
contributions to make.

--Ed
Edward Vielmetti
emv@ox.com

(note: the gateway may be mangling my address.  please advise if you
get this by mail and the From: line is weird.)

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 02:44:58 GMT
From:      rbaliga@udel.edu (Rajesh Baliga)
To:        comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.iso.dev-environ
Subject:   APPLICATION LAYER


 
I WOULD BE THANKFUL IF SOMEONE IN THIS NEWS GROUP ENLIGHTENS
 
ME ON WHAT THE FOLLOWING ABBREVATIONS STAND FOR.THE ONLY THING

I KNOW ABOUT THESE ABBREVATIONS IS THAT THESE CORRESPOND

TO DIFFERENT SERVICE ELEMENTS IN THE APPLICATION LAYER OF THE

7-LAYERED OSI REFERENCE MODEL.THE ABOVE-MENTIONED ABBREVATIONS

ARE THE FOLLOWING:
                  DPSE, TPSE, CCRSE, JMTSE, DCSSE, DCRSE, DMSE, DSSE,
                 
                  DRSE, DCMSE, DCSSE, MSSE, MDSE, MASE.


MY EMAIL ADDRESS IS RBALIGA @SOL.CIS.UDEL.EDU

THANKS IN ADVANCE.

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 11:52:31 GMT
From:      jel@tuura.UUCP (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp/Ip on Token-ring (VMEbus)

mbh@copsw33.UUCP (Marc Hasson) writes:

>Does anyone know of a vendor which manufactures Token-ring cards for a
>VMEbus machine?  So far I've confirmed (verbally only) that Interphase
>and CMC both have intelligent Token-ring VMEbus cards but I'd really
>prefer a "dumb" card, if possible.  A 6U form factor is a requirement.

One alternative might be the Formation fv1600 adapter:
- single 6U VME board
- operates at 4 or 16 Mbps (jumper selectable)
- uses TI TMS380C16 COMMprocessor and TMS38053 ring interface chipset
- 512 KB of Token Ring buffer memory
- uses shared memory to communicate with host
- driver software for SunOS 4.x with RFC 1042 compatible IP and NIT
  access (no promiscuous mode or multicasts, though).

A pretty nice product; our company is likely to begin to sell it.

Contact information for the company:

Formation, Inc.
121 Whittendale Drive
Moorestown, NJ 08057

Tel: (609) 234 5020
FAX: (609) 234 8543

Our contact person has been Roger M. Wyer but I do not know if
he is the right one for you.

Best regrards,

Jerry Lahti
Nokia Data Systems Oy, Systems Division/Network Operating Systems
Domains: jel@xerver.data.nokia.fi

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 14:45:14 GMT
From:      ian@unipalm.uucp (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS on VAX and TCP/IP on OS/2?

mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) writes:

>Brad Knowles asks...
 
>> Could someone refresh my memory as to what is available on VAXen for DNS
>> server software?
 
>Don't know for sure offhand, but it seems like our Wollongong stuff uses
>DNS on VAXen.

MultiNet from TGV and Fusion from Network Research both have DNS servers.

>> BTW, does anyone know of a full suite of TCP/IP applications written to run
>> on OS/2 (with the 3Com Ethernet software)?
 
>3Com's 3+Open TCP/IP includes an OS/2 version as well as a DOS version.

FTP Software do, and this little firm called IBM have had a go as well,
although their latest effort involves yet another standard adapter
interface, so I don't know of the support for 3com cards.

Disclaimer: we sell some of the software mentioned above (guess which :-)

Ian
... what's a .signature file?

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 15:09:18 GMT
From:      williams@vrdxhq.verdix.com (Tim Williams)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs
Subject:   Novell and packet drivers




Has anyone out there been successful in using NOVELL netware 386
with a driver using the packet driver spec or the NDIS spec
(for both client and server).

Also is it possible to use something like PC TCP from
FTP software at the same time that the NOVELL stuff is running 
on the client systems.

Thanks in advance
Tim Williams

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 15:32:22 GMT
From:      mra@srchtec.searchtech.com (Michael Almond)
To:        comp.protocols.tcp-ip
Subject:   Shutdown problems

We are currently connected with PSINet via SL/IP and every day or so I get the
followin error when I try pinging:

ping: wrote 192.33.4.100 64 chars, ret=-1
ping: wrote 192.33.4.100 64 chars, ret=-1
ping: sendto: No buffer space available

Once these errors show up, nothing seems to be going over the SL/IP connection.

Does anyone know what buffer this error is refering too?

-- 
Michael R. Almond (Georgia Tech Alumnus)          mra@srchtec.uucp (registered)
search technology, inc.				            mra@searchtech.com
4725 peachtree corners cir., suite 200		    {uupsi,stiatl}!srchtec!mra
norcross, georgia 30092				        (404) 441-1457 (office)

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 18:25:38 GMT
From:      cliff@garnet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re: Third party traceroute (source-route traceroute)

In article <EMV.91Feb20005703@poe.aa.ox.com>, emv@ox.com (Ed Vielmetti) writes:
|> 
|> As far as I know, the traceroute package on zerkalo and the 4.3
|> bsd-reno traceroute on (e.g.) wuarchive.wustl.edu are the latest of
|> the publically available traceroute implementations for BSD Unix.
|> 
|> There is no way to know what all else other people might have hacked
|> into the code, in their own effort to make it complete.  If someone has
|> done this they haven't spoken up.
|> 

OK, I'll speak up.  The Zerkalo package is wonderful.  It is also available
on ftp.cc.berkeley.edu, along with my two trivial hacks:

1)  The -n option now works.

2)  It attempts to detect assymetric routes (the Open Jaw routing problem).

    It does this by examining the TTL in the ICMP Time Exceeded messages
    returned by each hop.  It turns out that this method is flawed because
    there are at least 6 commonly used initial values for TTL in ICMP
    messages (29, 30, 59, 60, 255, and TTL_in_packet_received).  

So far I have found this second feature useful exactly once.  Other times
it has been interesting, but nothing more.

	Cliff Frost
	UC Berkeley

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 21:22:12 GMT
From:      efeustel@prime.com (Ed Feustel)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS on VAX and TCP/IP on OS/2?


IBM TCP/IP 1.0 and 1.1 for OS/2 EE supports 3Com Ethernet cards including the
3C523 and I believe the 3C503. It supports DIX2.0 and IEEE 802.3 packet formats.
It has client and demon for telnet, tftp ftp, rexec, sendmail, and a number of
other standard utilities.  At version 1.1 it supports NFS but with some 
security holes.  It provides Kerberos support, an RPC package, a sockets package,
terminal emulation for VT100, IBM3101, ANSI, and 3270 terminals.  It seems to 
work well on my PS/2 80-111.  I use the packages to work with Prime, MIPS, Sun, 
Apollo, and IBM.

Ed

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      20 Feb 91 22:57:19 GMT
From:      tr@samadams.princeton.edu (Tom Reingold)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet and ftp for DEC's SysV UN*X

In article <15136@lanl.gov> jrr@lanl.gov (John R. Red-horse) writes:

$ We are running a DEC version of System V (I believe it's r3) on a VAX
$ 8540.  The version of ftp imposes a hard limit on file sizes somewhere
$ in the neighborhood of 1Mbyte.  I assume that this is a parameter that
$ can be changed, but I don't have the source to do the fix.  Does
$ anyone out there know where I might obtain such an animal?  Better
$ yet, how about a version that's already fixed?
$ Cheers,

I suspect that this is not a limitation imposed by ftp but rather a
parameter in the kernel called the ulimit.  The ulimit limits the size
of a file of a process and its children.  This is often set at one
megabyte.  This supposed to prevent runaway processes from eating up
available filesystem space.  My feeling is that it causes more problems
than it prevents.

If you are root, type "ulimit 8192" and you will be able to create
files of up to 8192 blocks in your current shell.  This does not set
anything for other users or for root at a later time.  To change the
system-wide ulimit value, you have to reconfigure your kernel.

The above information is for System V.  It has nothing to do with
Berkeley UNIX.
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
        from windshield before starting ignition."

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 04:17:22 GMT
From:      jbev@iscden.jbsys.com (Jim Bevier - J B Systems)
To:        comp.protocols.tcp-ip
Subject:   unix driver for ka9q tcp/ip


I have downloaded the UNIX (sys5) version of ka9q.  It seems it only
works with slip or ax25 interface.  There is not an ethernet handler
included.  I would like to add a Western Digital 8 bit ethernet board
to my system to talk to other standard tcp/ip systems.  I need some
sort of a bare driver.  There are all kinds of DOS drivers, but no
UNIX driver.  Anybody know where I can get one?  Even something close
to use as a prototype would be useful.  I have ftp access.

Thanks in advance.

Jim Bevier
jbev@jbsys.com

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 07:21:27 GMT
From:      sgs@rand.mel.cocam.oz.au (Stuart Szabo)
To:        comp.protocols.tcp-ip
Subject:   Looking for source for CUTP

Does anyone know where I can file request the Clarkson University's
version of NCSA's telnet and ftp?

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 09:07:09 GMT
From:      thomas@nexus.se
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP using streams?

In article <MEB.91Feb20105117@orac.ee.mu.OZ.AU> meb@ee.mu.OZ.AU (Matthew Barry) writes:

   Can anyone tell me which operating systems have implementions of
   TCP/IP using streams modules?

I have a related question.
I'm in dire need of a TCP/IP streams implementation where I can separate
TCP and IP.

I've been checking WIN/TCP 3.1.0 for the 386 and it is streams only
above TCP.

The WIN/TCP drivers seems to be layered much like a streams stack. Are the
interfaces between the layers open and would it be feasible to put a packet
level module between TCP and IP in these drivers?

Znks.
Thomas
--
Real life:      Thomas Tornblom             Email:  thomas@nexus.se
Snail mail:     Communicator Nexus          Phone:  +46 18 171814
                Box 857                     Fax:    +46 18 696516
                S - 751 08 Uppsala, Sweden

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 13:32:56 GMT
From:      mikoh@IDA.LiU.SE (Mikael Ohlsson)
To:        comp.protocols.tcp-ip
Subject:   Socket problems



I have some problems with a socket connection. To read and
write a character from a socket takes about 1ms each. To write 
an integer takes about 1ms, but to read an integer takes about 180ms.

My question is: Why does it take so long time to read an integer
from a socket?  
Has it something to do with setting up the socket?

The processes communicates via a stream-socket connection 
between two Sparcstations and the underlying protocol is TCP.

I don't know wery much about network programming so I would
really appreciate if somebody could give me a clue.

--
---------
Mikael Ohlsson, IISLAB, Department of Computer and Information Science, 
Linkoeping University, Sweden
Internet: mikoh@ida.liu.se, UUCP: enea!liuida!mikoh, BITNET: mikoh@seliuida

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 16:12:08 GMT
From:      billy@vaxb.acs.unt.edu
To:        comp.misc,comp.protocols.tcp-ip
Subject:   Internet Library Guide

Hi,

The latest version of "UNT's Accessing On-line Bibliographic Databases" handout
is now complete.  It now contains 168 library systems covering 220 sites.

Credit for most of the new information goes to Dana Noonan, Metro State
University (for all the UK info) and Peter Scott, University of Saskatchewan.

Included at the end of this letter is the answer to some questions that have
popped up on numerous occasions.  Further discussion should take place on
preferably the PACS-L or LIB_HYTELNET mailing lists.

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX/Unix Systems Manager      THENET : NTVAX::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAX::BILLY
================================================================================

Some commonly asked questions:

How do I acquire the files?

The files are available on vaxb.acs.unt.edu (129.120.1.4) via anonymous FTP.  
The files are:

LIBRARIES.TXT - ASCII version
LIBRARIES.PS  - Postscript version
LIBRARIES.WP5 - WordPrefect 5.1 source (transfer in binary mode)
LIBRARIES.ADR - Numeric IP addresses of Internet libraries
LIBRARIES.CONTACTS - Contacts for some of the Internet libraries
NETWORKS.HLP - VMS help file source for a wide area networks help topic,
               which includes a section on library systems.

BITNET only users should use the BITFTP service to acquire the files.  I do not
personally know how to use BITFTP.  However, it is definitely not accessed by
sending mail to BITFTP@UNTVAX.  As an absolute last resort, the files may be
requested via email (note: some networks such as UUCP may file size limits that
may prohibit the transfer of these documents through electronic mail).


Why is there UNT's guide and the Art St. George/Ron Larsen guide?

Art St. George and I have some differences of opinion in the area of formatting
and what should be included in an Internet library guide.  Though I could just
use the St. George guide, I need to format the information into a easy to use
for novice computer users for my on-campus users.  It is not much harder to
provide it to the Internet at large and also gather my own information.  Joe
St. Sauver, the author of the VAXbook, on PACS-L put forth a rather good 
argument for the case that two guides are actually a benefical thing.

By the way, I think Art St. George's claim of FIRST, BEST, and MOST 
AUTHORITATIVE is incorrect.  If anybody deserves FIRST, it is Joe St. Sauver.  
MOST AUTHORITATIVE is without a doubt the Internet Resources Guide.  BEST is a
matter of opinion.  I will not make any claims about my guide besides that many
people find it useful.

Are there some other useful sources of information?

1.  HYTELNET - A Hypertext database for MS-DOS systems on Internet Resources
        including Library systems.  Available via anonymous FTP on
        WUARCHIVE.WUSTL.EDU, WSMR-SIMTEL20.ARMY.MIL, or VAXB.ACS.UNT.EDU.
        Written by Peter Scott, University of Saskatchewan.  A new version
        should be released in the near future.

2.  LIBTEL - A TELNET front-end for VMS and Unix system to access Library
        Systems.  Available via anonymous FTP on VAXB.ACS.UNT.EDU.  Written
        by D. Mahone.

Where do I send updates?

Send all new information, updates, and deletions to BILLY@VAXB.ACS.UNT.EDU 
(more details on first page of guide). If you are using a TELNET/TN3270 package
not listed in the appendix, please send me the information on it.  Also, if you
have instructions for a library software package not yet described, please
send them to me and give me at least one example where it is in use.  Sorry
about the Appendices on some library software that are not yet completed.  I
will complete as time permits.

Why don't you use a smaller font size to save paper?

To keep 80 characters or less per line is the major reason.  Also, a smaller
font will not save that much paper (I've looked at it).

I have problems printing the PostScript file.

I'm pretty clueless on this one.  I have printed the PS file from a PC to an
Apple Laserwriter II without a problem.

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 17:31:51 GMT
From:      lr@cs.brown.edu (Luigi Rizzo)
To:        comp.protocols.tcp-ip
Subject:   Simple nameserver source ?

Where can I find the sources for a simple nameserver for Ultrix
2.2 ? Need nothing special, just something that reads the local
/etc/host file - the machine is only connected to a local network
with other Unix, Mac and MSDOS machines running NCSA Telnet.
	Thanks
	Luigi
==================================================================
Luigi Rizzo                Brown University & Univ. di Pisa
e-mail: lr@cs.brown.edu, luigi@iet.unipi.it
==================================================================

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 18:48:31 GMT
From:      root@siihp1.epfl.ch
To:        comp.protocols.tcp-ip
Subject:   tcpdump


   Does anybody knows about a program like etherfind or tcpdump
for hpux systems. thanks for your answers.


                    Claude Lecommandeur
                    Service Informatique Central
                    Ecole Polytechnique Federale de Lausanne
                    1015 LAUSANNE (SWITZERLAND)
                    E-Mail : lecom@sic.epfl.ch
                    Tel : (41 21) 693-45-86

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 19:44:02 GMT
From:      nolet@se-sd.SanDiego.NCR.COM (Jason Nolet)
To:        comp.os.os2.misc,comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Looking for OS/2 TCP/IP products with RFC 1001/1002


Hello OS/2 Users or Programmers!

We are looking for a TCP/IP product on OS/2 which offers a NetBIOS I/F via 
RFC 1001/1002.   Can you offer any recommendations?  I understand that 
3Com offers a TCP/IP product for OS/2, but I don't know any details.  I 
would be most interested in the "more popular" TCP/IP-for-OS/2 products 
on the market.

Thanks for your help!

/******************************************************/
/* Jason Nolet                                        */
/* Network Products Div. - San Diego, NCR Corporation */
/* email:  Jason.Nolet@SanDiego.NCR.COM               */
/* Phone:  (619) 578-9000                             */
/* Fax:    (619) 693-5705                             */
/******************************************************/

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 19:45:29 GMT
From:      tkevans@oss670.UUCP (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   Curious Behavior of 4.2BSD TCP/IP

I have a VAX 11/750, with 4.2BSD (NOTE:  4.2, not 4.3), which I'm
trying to place onto my network and am having curious results.  (Before
describing them, I have to say that I cannot upgrade to 4.BSD, so
must deal with the situation as is.)

Our network formerly consisted of 6 separate networks, which have only
recently been bridged with hardware bridges into a single spanning
tree network.  Prior to the bridging, I'd implemented subnetting in
our class B address space, with a netmask of 255.255.255.0.  Each 
of the 6 networks was a subnet.  Now, I still maintain the fiction of
having 6 subnets, even though they're all the same cable.  (I'd really
rather not have to go back to all machines and rip out the subnetting
stuff.)

I set up /etc/networks showing the 6 "subnets."  Here's what it looks
like:

loopback	127
oss-lan		137.200
lan1		137.200.1 localnet	# VAX is on this subnet
lan2		137.200.2
lan3		137.200.3
lan4		137.200.4 
lan5		137.200.5
lan6		137.200.6

In addition, the VAX's rc.local installs routes to each of the 5 "subnets"
outside its own, as shown below:

route add lan2 `hostname` 0
route add lan3 `hostname` 0
route add lan4 `hostname` 0
route add lan5 `hostname` 0
route add lan6 `hostname` 0

The VAX, which is on "subnet" 1 can see and access all machines on
"subnets" 1, 2, and 3, but not on 4, 5, and 6.  Similarly, machines
on "subnets" 1-3 can telnet/ftp to the VAX, but those on 4-6 cannot.

The next curious thing is that even after installing the routes to
the "subnets," 'netstat -r' doesn't report them.  All that's reported
is the route to "osslan"  (see networks file above).

More interestingly, if I reassign the VAX's IP address to one in 
another "subnet" (say, "subnet" 5, one that's *not* reachable) and
modify the /etc/networks and installed routes accordingly, I have the
same results as before!  That is, even with an IP address in "subnet" 5,
the VAX can see *only* "subnets" 1-3, and not 4-6.

Now, I could understand it if the VAX couldn't see *anything* outside its
own "subnet"  (4.2BSD doesn't know about subnets, right?), but the fact
that it can see some but not others is really confusing.  And, that it
can see/not see the same subnets, regardless of its own "subnet,"
makes it even more curious.

Comments?  Suggestions?  (That is, other than upgrading the BSD.)
Thanks.
-- 
INTERNET	tkevans%woodb@mimsy.umd.edu
UUCP 		...!{rutgers|ames|uunet}!mimsy!woodb!tkevans
US MAIL		6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD  21235	
PHONE		(301) 965-3286

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 21:15:34 GMT
From:      rwmira01@ulkyvx.bitnet (Rob Miracle)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Help with Anonymous FTP

Good Day!  I know this question has been asked here before, but since I have
just started recently reading these groups I thought I would ask.

I am trying to set up an anonymous FTP account on my AT&T box.  We are running
System V R 3.2.2 from AT&T and the AT&T ENHANCED TCP/IP WIN/386 package
(Wollongong).  In the Installation and Administration Guide it says:

"If the username is "anonymous" or "ftp" and an "anonymous" account is present
if /etc/passwd, the user is allowed to log in by specifying any password.  Since
anyone can log in under "anonymous," it is wise to restrict the access
privileges of this account."

Problem #1, AT&T SVR3.2.2 only allows 8 character file names, thus "anonymous"
can not be created.  By hand editing /etc/passwd and /etc/shadow, I added the
account as:   anonymous:x:1000:100:FTP Anonymous Account:
and put the proper enter in /etc/shadow.  Now I can FTP to a real account and
it works find (had to get that one out).  When I try to login, it barfs saying
that it can't login to anonymous.  I try various tricks, such as logging in as
ftp and anonymou but to no avail.  I try the next logical thing.  I remove the
anonymous account and add an account called ftp.  Now I can log in, but any
access other than CD barfs with a message:

PORT 136,165,2,12,8,17
200 PORT command okay
NLST
425 Data Socket not created [0.0.0.0,0]

(This is from a VMS host), and from an unix host:

200 PORT command okay
425 Data Socket not created [0.0.0.0,0]

Now I can log in as a real person and it works.  CD commands seem to work fine,
but I can't test them beyond not getting an error message.  I tried it with and
without a password of the ftp account.

Problem #2  It seems that the CD command can get anywhere on the system.  How
do I restrict it to just the tree that I want it in?

Thanks in Advance
Rob 
-- 
Rob Miracle              | Bitnet   : RWMIRA01@ULKYVX    CIS: 74216,3134
Programmer/Analyst-II    | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu
University of Louisville | UUCP     : ...psuvax1!ulkyvx.bitnet!rwmira01
"Revenge is a dish best served cold.  It is very cold in space" 
       -- Ancient Klingon Proverb

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 21:52:33 GMT
From:      dbjoyner@eos.ncsu.edu (David Joyner)
To:        comp.protocols.tcp-ip
Subject:   Cisco information needed

I need some information regarding Cisco routers.  Specifically, how can I
query the Cisco with SNMP (or some other protocol) and get information
about subnets that the router services as well as what machines are on
these subnets?  The technical information that I have available is lacking.

I would appreciate it if a programmer from Cisco could mail me...

+===========================================================================+
| David B. Joyner (dbjoyner@eos.ncsu.edu) | North Carolina State University |
 +---------------------------------------------------------------------------+
|   "Typically supercomputers use a single microprocessor." -Boston Globe   |
+===========================================================================+

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 22:00:35 GMT
From:      etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.tcp-ip
Subject:   SNMP test

Hi,

Could some SNMP-able person on the net help me with a test of our 
ethernet spy debugging ?

We have a beta version of out ethernet spy Beholder running on:

	beholder1.et.tudelft.nl

This spy can report it's findings through SNMP. We have developed our own
UDP/IP stack with a SNMP library. Our in-house testings work ok, but I
would like some external testing.

Could somebody try to reach the above host, and request the SNMP variables
in the 'public' community ?

Thanks for the trouble

Jan


-- Ir. Jan van Oorschot.             --- Email: JPMvOorschot@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 --

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 22:28:25 GMT
From:      pjs@euclid.jpl.nasa.gov (Peter Scott)
To:        comp.protocols.tcp-ip
Subject:   Novice questions on TCP programming

I have just started programming in TCP and am up to my ears in
manuals.  I'm trying to get the basic concepts I need with the
aid of Douglas Comer's book, but it's hard to see the wood for
the trees; there's so much information there that I don't need,
it's hard to tell what I do need.

I have a simple application to complete: a server running on SunOS
catches binary records sent from a MicroVAX running Multinet on VMS,
which records are from a file on a machine available via DECNET to
the Microvax but not the Sun.  The idea is to mirror the file on the
Sun; hence I have a detached process on the MicroVAX checking it at
appropriate intervals.  I have been able to figure out how to
create sockets and make connections and have transferred data.  So
far so good.

The problems come in trying to handle failure modes, e.g., one machine
up, one down.  I haven't been able to find out what happens when the
VAX attempts a socket_write() but the Sun has gone down in the meantime;
is there a timeout for the write?  How long is it and how do I change it?
Or are there timeouts only on connect()s, and ditto?  Would I get
an ENXIO error if the write failed?  I'm trying to determine what's
fatal and what isn't, both when I'm trying to make a connection and
after it's been made; would any error on the write() call mean that
I'd have to go back to trying to reconnect?

I realize that I may be hopelessly lost; I've seen enough novice
questions in areas I do know something about to know what kinds of
mistakes can be made.  Thanks in advance.

-- 
This is news.  This is your       |    Peter Scott, NASA/JPL/Caltech
brain on news.  Any questions?    |    (pjs@euclid.jpl.nasa.gov)

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      21 Feb 91 23:46:04 GMT
From:      macfreak@athena.mit.edu (Gene P Sohn)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.sys.mac.apps,comp.unix.questions,comp.protocols.nfs
Subject:   Info on filesystem for Mac network connected to UNIX


Hi, I've never used the news net before, so I apologize beforehand for
any and all etiquette violations and whatever else I'm not supposed to
do, including sending this to newsgroups to which this message doesn't
apply.

Anyway, I'm researching the different possibilities for filesystems
for a Mac-UNIX configuration.  The catch is that the UNIX we're
connecting to is non-standard--that is, we use Kerberos authentication
on a 4.3 bsd UNIX.

Frankly, I'm pretty new to networking and so I really have little idea
where to start.  My advisor has given me a couple of programs to
research, and also hunt for any public-domain programs which might do
the trick.

Therefore I'll ask about Gatorbox, and TOPS.  Does anyone see a
problem with using either of these programs, or even better, does
anyone have a running Mac/UNIX net using Gatorbox or TOPS?

Opinions concerning the relative merits of Gatorbox, TOPS, and just
about any other MAC fileserver program would be appreciated, in
addition to what Kerberos can do to these programs' ability to run
effectively, if it has an effect.

I know this is, at best, a rough wording of the problem, but I hope
someone can help me.  Feel free to educate me on any aspect of
networking in the process--I really feel pretty ignorant.  :-)

Again, the basic objective is a fileserver program which allows the
Mac to access an existing (that might be important) UNIX network which
uses Kerberos.

Please reply to me directly, if possible.  I only check news
infrequently and irregularly.  Thanks!!

Gene Sohn
macfreak@athena.mit.edu
Compuserve: 72427,2602

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 91 00:37:31 GMT
From:      mjhammel@Kepler.dell.com (Michael J. Hammel)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP using streams?

In article <MEB.91Feb20105117@orac.ee.mu.OZ.AU>, meb@ee.mu.OZ.AU
(Matthew Barry) writes:
> Can anyone tell me which operating systems have implementions of
> TCP/IP using streams modules?

The sockets implementation of TCP/IP is done in a STREAMS framework (as
stated in the AT&T System V Release 4 Programmer's Guide: Networking
Interfaces) for System V Release 4.  I believe ISC's TCP/IP (1.1.2 and
1.2 that I know of) package is also done over streams, but am not
completely sure of that.

Michael J. Hammel        | mjhammel@{Kepler|socrates}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel
#define CUTESAYING "Lead, follow, or get the hell out of the way."

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 91 05:49:11 GMT
From:      david@gara.une.oz.au (David Macalpine)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.modems,comp.protocols.appletalk,aus.mac
Subject:   Help needed with AppleLink via network


I have a problem in connecting to AppleLink from my work computer.
I am using a Mac SE30 and hoping to be able to use the AUSTPAC (X25)
facilities available on a network SPARCServer 330 in place of the
messy business of dialling out (or trying in the case of our phone
system) and then connecting to the X25 network and thence to AL.

My problem is in filling in the gap in the diagram below.

X.25 network (AUSTPAC)
	|
	|
 The SUN with X.25 PAD
	|
  TCP/IP
	|
	|
  GatorBox
	|
 Localtalk
	|
 My Mac's serial port
	?
	?
	?
  AppleLink 6.0

I currently use MacTCP version of NCSA Telnet (2.3) to connect to the SUN
with no problem.

Thanks in advance for any help that you may be able to offer.

Please send replies by email.  Thanks again.

David

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 91 06:55:08 GMT
From:      Z00EJR01%AWIUNI11@pucc.PRINCETON.EDU (Ewald Jenisch)
To:        comp.protocols.tcp-ip
Subject:   Preventing zone transfers from nameservers

We're running a "bind" nameserver under Unix for some time now.

I'm looking for a way to restrict zone-transfers from nameservers.
Put in another way I only want certain hosts in the net to do a complete
zone-transfer (namely official "secondary nameservers") - the rest of
the nameservers/nslookups out there should be able to query our nameserver
for IP-addresses or inverse queries but NOT a complete zone-transfer.

Any ideas how I could get that working? Are there any modifications
necessary in the "named"-sources?

I've already looked at the "assigned numbers" but didn't find a dedicated
TCP/UDP port for AXFER queries - seems all nameserver queries run over
port 53 (both UDP and TCP).

Thanks in advance for any information,

Ewald JENISCH                                    NIC-Handle: EJ51
University Computer Center; University of Vienna, Austria
E-Mail: z00ejr01@awiuni11.bitnet or z00ejr01@helios.edvz.univie.ac.at
Snail-Mail: Universitaetsstrasse 7; A-1010 Vienna, Austria, Europe

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 91 08:25:55 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   Need RPC-Library for PCs (MSDOS)

Hi Netland,

I'm desperatley seeking an RPC-Library (especially the RPC client stuff) for
MS-DOS. I know that FTP offers such a library in the States but their German
Distributors don't have it and can't get it fast. But I need this really fast.
Any hints on other stuff greatly appreciated.


			Thanx in advance

				-Torsten
--
Torsten Beyer                      e-mail : tb@Materna.DE
Dr. Materna GmbH		   VOX    : +49 231 5599 225
Vosskuhle 37			   FAX    : +49 231 5599 100
D-4600 Dortmund 1,  West Germany

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 91 09:33:08 GMT
From:      chewcg@hpsgm2.sgp.hp.com (Chye Guan Chew)
To:        comp.protocols.tcp-ip
Subject:   SNMP Offering?

hi, 
   I am interested in knowing vendors such as IBM, DEC, Data General,
   Unisys and 3Com implementation of SNMP stack.  Do they provide a 
   programmer developer kit for accessing the SNMP stack?
   Do they have multiplexing SNMP capability?

   Any information about these vendors or any vendors' offerings are welcome.



   Thanks

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 91 09:55:09 GMT
From:      a20@nikhefh.nikhef.nl (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   ICMP source quench

Hi all,

Can anyone tell me what causes an ICMP source quench message to be sent ?
As far as I can tell this message has something to do with the load on an
interface and tells a host to slow down the sending of packets. I notice a
lot of these messages on my cisco with a heavily loaded serial interface
(mostly 70-80% of the 64 Kbit/s).

What do hosts that recieve this messages do with it ? Can it cause an ICMP
Network is down ? Does it in any way have an effect on outstanding TCP
connections ?

Thanks for any hints,

Marten
--
Marten Terpstra                                  National Institute for Nuclear
Internet : terpstra@nikhef.nl 		                and High Energy Physics
Oldie-net: {....}mcsun!nikhefh!terpstra	      (NIKHEF-H), PO Box 41882, 1009 DB
Phone    : +31 20 592 5102                           Amsterdam, The Netherlands

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 91 18:33:10 GMT
From:      tengi@princeton.edu (Christopher Tengi)
To:        comp.protocols.tcp-ip
Subject:   Re: Subject: traffic monitoring by net snooping

Jeff,

In article <1991Feb16.014841.10155@pa.dec.com>, mogul@wrl.dec.com (Jeffrey Mogul) writes:
|> In article <85756@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> >Trying to keep up with and properly filter network traffic from an Ethernet
|> >or FDDI MAC in promiscuous mode requires substantial support below the
|> >application.  Such support, if present, is not currently likely to be
|> >sufficiently similar on products from hardware vendors.
|> 
|> I've ported a number of such programs, and (if the program structure
|> is at all modular) it turns out to be pretty easy to get a program
|> (e.g., tcpdump, nfswatch, statspy) to run on the following systems:
|> 	Ultrix + Ultrix packet filter
|> 	SunOs + NIT
|> 	4.xBSD + new "Berkeley Packet Filter" (BPF)
|> and possibly the IBM RT using the modified Stanford packet filter done
|> by some folks at Merit.
|> 

I assume, from reading the above, that you did work on tcpdump and
statspy to make them work with the Ultrix packet filter.  If this is
true, have your changes been melded back into the "original" sources
for the rest of us to use?  If not that, would you be willing to make
patches available?

					/Chris

-- 

==========----------==========---------+---------==========----------==========

	UUCP:	  ...princeton!tengi		VOICEnet: 609-258-6799
	INTERNET: tengi@princeton.edu		FAX:      609-258-3943
	BITNET:	  TENGI@PUCC

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      22 Feb 91 21:48:33 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Cisco information needed

In article <1991Feb21.215233.26519@ncsu.edu> dbjoyner@eos.ncsu.edu (David Joyner) writes:
>I need some information regarding Cisco routers.  Specifically, how can I
>query the Cisco with SNMP (or some other protocol) and get information
>about subnets that the router services as well as what machines are on
>these subnets?  The technical information that I have available is lacking.

Do you have "The Simple Book" by Marshall Rose, which describes SNMP?  If
you're going to be using SNMP much I suggest you run, don't walk, to a
bookstore with a good technical section and get it.

To find out the IP addresses of an interface, you find the rows in the
ipAddrTable where the ipAdEntIfIndex is the interface number.  The
corresponding ipAdEntAddr is the address of that interface.  You can also
get the corresponding ipAdEntNetMask to get the subnet mask, and apply this
to the address to get the subnet address.  By doing this for all the
interfaces, you can get a list of all the subnets connected to the router.

If you want to get a list of all the subnets that the router knows about,
you should dump the ipRoutingTable.

I don't think the router maintains a list of all the machines on a subnet
(how would it get such a list?), so there's no way to list it with SNMP.
If you have accounting turned on you may be able to get a list of all the
hosts that have used the router.

You can also FTP cisco's enterprise MIB from ftp.cisco.com.  This documents
all of cisco's implementation-specific extensions to the MIB.

>I would appreciate it if a programmer from Cisco could mail me...

You should send mail to customer-support@cisco.com if you want response
from cisco.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 02:44:32 GMT
From:      mogul@wrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: problem with ftp

In article <36540022@hpindwa.cup.hp.com> raj@hpindwa.cup.hp.com (Rick Jones) writes:
>A bit of drift, but which routers support MINMTU (RFC 1191) at this
>point?...

I don't know of any routers which support the new form of ICMP message
defined in RFC1191, but it is important to understand that the protocol
was designed to work with any router that conforms to existing standards
(for IP and ICMP).  You just get faster results when the routers implement
RFC1191.

For 4.3BSD-based routers: I did a pilot implementation while writing
the RFC, and I can provide the necessary changes.

To be sure: if any router vendor does implement RFC1191, I probably
wouldn't know about it.

-Jeff

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 02:51:02 GMT
From:      mogul@wrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Subject: traffic monitoring by net snooping

In article <6507@idunno.Princeton.EDU> tengi@princeton.edu (Christopher Tengi) writes:
>Jeff,
>I assume, from reading the above, that you did work on tcpdump and
>statspy to make them work with the Ultrix packet filter.  If this is
>true, have your changes been melded back into the "original" sources
>for the rest of us to use?  If not that, would you be willing to make
>patches available?

Your inference is correct.  Tcpdump version 2.0 includes Ultrix support;
you can get it from
	ftp.ee.lbl.gov:tcpdump-2.0.tar.Z (and see tcpdump-2.0.patch-1)
	gatekeeper.dec.com:pub/net/tcpdump-2.0.tar.Z
I'm pretty sure that the gatekeeper version has the patch installed
and has a Makefile which is ready-for-Ultrix.

My changes to NNstat (statspy) have been provided to the folks at ISI, and
I expect them to appear in the imminent release.

-Jeff

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 03:38:31 GMT
From:      echan@cadev6.intel.com (Eldon Chan ~ )
To:        comp.protocols.tcp-ip
Subject:   Timeout mechanism to invalidate ARP cache entries

On page 23 of RFC1122 (Requirements for Internet Hosts--Communication
Layers) under the DISCUSSION paragraph said this:

   " The ARP specification [LINK:2} suggests but "DOES NOT" require a
timeout mechanism to invalidate cache entries when hosts change their
Ethernet addresses "

Would someone tell me what are implemented and how it is done on SunOS,
Ultrix and other UNIX machines ?

The RFC mentioned four mechanisms-- timeout, unicast poll, link-layer
advise and high-layer advice. So, which OS is using which mechanisms ?

Thanks in advance for your input.

Eldon Chan
Design Technology
Intel Corporation
echan@scdt.intel.com

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 06:14:57 GMT
From:      ljm@vaxeline.COM (Leo J. McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   LPR as RFC 1179 (was: Is there a protocol for remote printing)


>Does a standard protocol exist for remote printing on tcp/ip ? I have
>been looking in RFC's and in different litterature for a specification,
>but haven't found one. 
  
>I am also interested in specifications for the protocol used by the BSD
>lpd daemon, and if such a protocol exists for SYSV also the protocol
>used by the lpsched.

LPR is indeed what you are looking for, it is described in RFC 1179.
It is a slight superset of the BSD implementation so as to make LPR
useful for non-UNIX systems.

enjoy,
leo j mclaughlin iii
ljm@ftp.com

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 08:09:39 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP source quench

In article <1155@nikhefh.nikhef.nl> a20@nikhefh.nikhef.nl (Marten Terpstra) writes:
>Can anyone tell me what causes an ICMP source quench message to be sent ?
>As far as I can tell this message has something to do with the load on an
>interface and tells a host to slow down the sending of packets. I notice a
>lot of these messages on my cisco with a heavily loaded serial interface
>(mostly 70-80% of the 64 Kbit/s).

Your guess is pretty correct.  A router sends a quench when it has to
discard an IP datagram due to lack of buffer space.  The hope is that this
will cause the sender to slow down.  It can easily happen when forwarding
lots of data from a fast link to a slow link, if the packets are being
received faster than they can be forwarded, since the router only has a
finite amount of buffer space.

>What do hosts that recieve this messages do with it ? Can it cause an ICMP
>Network is down ? Does it in any way have an effect on outstanding TCP
>connections ?

The only thing a host should do when it receives a source quench is slow
its rate of transmission to that router.  It might do this by setting a
delay on the TCP connection that the source quench came from, or by setting
a delay attribute in the routing table entry to that destination.

See the Host Requirements RFC for more information on Source Quench.
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 15:20:34 GMT
From:      gsb1@forth.stirling.ac.uk (Mr Gordon S Byron)
To:        comp.protocols.tcp-ip
Subject:   Compressed Video Transport Requirements

Could you summarise your responses please as I am very interested in
where this technology is going, what we can reasonably expect from  it
within the next five years and how soon implementation would be
advisable. we have fibre optic cabling put in and hope to use
Compressed Video Transport as soon as it is finacially and technically
feasible.
Thanks for any responses

*******************************************************************************
Snailmail: Gordon Byron,  Arts Computing Advisor,Pathfoot Building, 
University of Stirling,FK9 4LA  Stirling, Scotland, UK.
Voice:  0786 73171: Ext 7266  Fax: +78651335
*******************************************************************************

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 15:47:59 GMT
From:      janm@dramba.neis.oz (Jan Mikkelsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Tandem 6530 terminal emulator (tn6530?)


While on the subject of Tandem 6530 terminal emulators, does anyone know
of a 6530 emulator with IXF file transfer for Unix?  Any flavour, but
preferably System V, rel 2 or 3.

Thanks,
-- 
Jan Mikkelsen
janm@dramba.neis.oz.AU or janm%dramba.neis.oz@metro.ucc.su.oz.au
"She really is."

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 18:12:20 GMT
From:      VOLZ@process.com (Bernard E. Volz)
To:        comp.protocols.tcp-ip
Subject:   Re: Timeout mechanism to invalidate ARP cache entries

In <2669@inews.intel.com> echan@cadev6.intel.com writes:

> On page 23 of RFC1122 (Requirements for Internet Hosts--Communication
> Layers) under the DISCUSSION paragraph said this:
> 
>    " The ARP specification [LINK:2} suggests but "DOES NOT" require a
> timeout mechanism to invalidate cache entries when hosts change their
> Ethernet addresses "
> 
> Would someone tell me what are implemented and how it is done on SunOS,
> Ultrix and other UNIX machines ?
> 
> The RFC mentioned four mechanisms-- timeout, unicast poll, link-layer
> advise and high-layer advice. So, which OS is using which mechanisms ?
> 
> Thanks in advance for your input.
> 
> Eldon Chan
> Design Technology
> Intel Corporation
> echan@scdt.intel.com

For Process Software Corporation's TCPware for VMS we flush an ARP cache
entry if we haven't RECEIVED a packet from the <Internet-Address>,<Ethernet-
Physical-Address> pair within a reasonable time period (typically 10 minutes).

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      23 Feb 91 20:09:45 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Timeout mechanism to invalidate ARP cache entries

In article <2669@inews.intel.com>, echan@cadev6.intel.com (Eldon Chan ~ ) writes:
> Would someone tell me what [ARP cache timeout mechanisms] are implemented
>	and how it is done on SunOS,
> Ultrix and other UNIX machines ?

The most reliable way to answer such a question is to check the source,
when possible.  That way you don't rely on hearsay and rumor.

I suspect 4.* BSD was influential in most versions of SunOs and Ultrix.
(Take that statement as hearsay or rumor).  The 4.3BSD-network-release code
is in arptimer() in .../netinet/if_ether.c in your favorite public source
repository, such as UUNET.  An official tape of the 4.3BSD network source
is cheap, and is required reading for any serious student of TCP/IP.

If you want a rumor of how 4.3BSD does it, mine is that it uses simple
timers which delete completed entries 20 minutes after creation.

Vernon Schryver,    vjs@sgi.com

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 91 02:28:22 GMT
From:      backman@vaxeline.COM (Larry Backman)
To:        comp.os.os2.misc,comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: Looking for OS/2 TCP/IP products with RFC 1001/1002

In article <4432@se-sd.SanDiego.NCR.COM> nolet@se-sd.SanDiego.NCR.COM (Jason Nolet) writes:
>
>Hello OS/2 Users or Programmers!
>
>We are looking for a TCP/IP product on OS/2 which offers a NetBIOS I/F via 
>RFC 1001/1002.   Can you offer any recommendations?  I understand that 
>3Com offers a TCP/IP product for OS/2, but I don't know any details.  I 
>would be most interested in the "more popular" TCP/IP-for-OS/2 products 
>on the market.
>

TCP/IP's for OS/2 that I am aware of:

FTP Software V1.1 (in beta right now) supports RFC 1001/2 NETBIOS
3Com's 3+TCP for LAN Mgr supports RFC 1001/2 Netbios.  It has been
shipping for a while.
IBM TCP/IP for OS/2 V1.1 does not to my knowledge support Netbios.
Ungermann-Bass is rumored to have an OS/2 TCP Netbios.  I have not seen it.
Excelan (now Novell) once shipped LAN Workplace for OS/2 w/ TCP & Netbios.
I have no idea if it still is shipping.
Racal-Interlan once shipped NP628, an intelligent card TCP/NETBIOS which
ran under OS/2.  I believe they have discontinued the product.

Thats the list that I am aware of.



					Larry Backman

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 91 17:44:12 GMT
From:      jessea@dynasys.UUCP (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Can a forwardee be a forwarder?

I'd like to know if a UUCP site that has a domain name and a forwarder
can itself be a forwarder for another UUCP site so that site can get a
domain name?  It would seem like a reasonable assumption, but....

---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---
      Jesse W. Asher                             Phone: (901)382-1609 
               6196-1 Macon Rd., Suite 200, Memphis, TN 38134
                UUCP: {fedeva,chromc,rutgers}!dynasys!jessea

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 91 21:42:10 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip,news.admin,comp.mail.misc
Subject:   What Is Difference Between Internet And X.400 Style Names?

Can someone please explain the difference between X.400 and Internet-style
names of the form: USER@SITE.DOMAIN?  I had thought that X.400 names
were of the form /THIS=,/THAT=,/ANDWHATEVER=.  Recently, two things
made me question this.  First, someone told me that the USER@SITE.DOMAIN
was an X.400 standard.  Second, I noticed that PSI offers an X.500
service as part of their TCP/IP public data network PSInet.  Their
advertising literature seems to imply that the X.500 database holds 
addresses of the USER@SITE.DOMAIN type.  I understand that "bang" style
names are unique to UNIX (a derivative of UUCP), but are the USER@SITE.DOMAIN
style names X.400 or UNIX standards, and what is the relationship to
the longer addressing form /THIS=,/ETC=?

Thanks,
Will Estes        (apple!cup.portal.com!Will)

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      24 Feb 91 23:30:00 GMT
From:      PH461A04@VAX1.UMKC.EDU (Guerra de Bureau)
To:        comp.protocols.tcp-ip
Subject:   Certified Mail Systems...



Regarding a protocol for SMTP certified mail, can anyone suggest
why the following procedure would not work??
	1) Local mail system encrypts mail with time-varying key
	2) Local system forwards mail to remote system
	3) Remote system delivers (encrypted) mail to designated user
	4) Designated user requests key from remote system
	5) Remote system requests key from local system
	6) Local system indicates to message originator that message
	   has been received and key requested.
	7) Local forwards key to remote
	8) If remote system does note recieve key withing (x) units,
	   repeats request for (y) tries before informing recipient key
	   unavailable
	9) Remote delievers key to remote user/unencrypts original message

The only failure that I see is if a) the remote system requests the
key from the local system; b) the local system acknowledges the request,
and c) the anknowlegment(key) never gets back to the remote, and finally
d) the remote is not able to re-request the key within the designated
time frame.  Given the increasing network reliability and the decreasing
network transfer time and a sufficient number of retries/length of
time before discard this system would seem fairly secure.

Any problems??

Jonathan E. Oberg
ph461a04@vax1.umkc.edu

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 00:11:03 GMT
From:      mussar@bcars53.uucp (G. Mussar)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over X25


In article <1991Feb17.163237.17152@informatik.uni-erlangen.de> eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) writes:
>
>Real life experience: Sun3/50: 9.6kbps, Sun3/xx(other than 3/50): 19.2kbps,
>Sun4/xxx: 64kbps - all over CPU ports. MCP ports 64kbps each, HSI 2Mbps.
>
I know the documentation for Sun4 ports indicates 64Kbps max, however,
running the port at 19.2Kbps shows large numbers of underruns when various
tasks are running. 
--
-------------------------------------------------------------------------------
Gary Mussar  |Bitnet:  mussar@bnr.ca                  |  Phone: (613) 763-4937
BNR Ltd.     |  UUCP:  ..uunet!bnrgate!bcars53!mussar |  FAX:   (613) 763-2626

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 13:01:27 GMT
From:      af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR as RFC 1179 (was: Is there a protocol for remote printing)

On Sun, 24 Feb 91 14:46:18 EST Bruce Crabill said:
>                                   A true LPR spec needs to be done, but
>RFC 1179 isn't it.
>
>                                       Bruce
I would say: a true remote printing protocol, useful in a scope a little
larger than one operating system, needs to be defined, but lpr isn't it.
                                                 /AF

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 15:33:52 GMT
From:      jaynes@med.umich.edu (William Jaynes)
To:        comp.protocols.tcp-ip
Subject:   Sendmail/SMTP/TCP mystery?


Someone felt that this problem may be a more general TCP protocol discrepancy
causing packets to be lost or ignored, so here is what I have posted elsewhere..

----------
Last week I noticed that messages to a particular host were being queued on
my mailhub.  The sendmail message  is

  (Deferred: Connection timed out during result wait with uv1.im.med.umich.edu)

These messages never get delivered.  All attempts fail until they time out and
are bounced.

The mailhub is a SunSLC.  The host in question is a Vax running some
Wollengong TCP-IP/SMTP etc. software.  Up until last week there was not a problem.
Both of us sys admins swear that we haven't changed anything. (of course)

Here are some facts:
    - A short message (less then about 1100 bytes) will be delivered.
      A longer message will not.
    - I forced my Suns (4.1 and 4.1.1) to skip the mailhub and mail direct
      and got the same results: longer messages were queued with the same
      deferred message.
    - I forced my Decs (Ultrix 4.0) to skip the mailhub and mail direct
      and did NOT get the same results.  Mail worked fine.
    - From my Suns, if I telnet to port 25 of the Vax and fake mail, I can
      send as big a message as I want.
    - From Suns that are not on my net (141.214) and which mail direct to the
      Vax, I can send as big a message as I want. (One is 4.0.3c)
    - This one Vax is the ONLY host with which there is a problem.
      Other Vaxen on the same ethernet don't have a problem. (I don't know
      if the other Vaxen use the same SMTP software.)
    - The data files are properly terminated with a 0x0a.

Using a Sniffer, I looked at packets during delivery attempts that failed.
The Suns simply aren't sending a <CR><LF>.<CR><LF> after the data is
sent.  Instead they send the data again and again until the connection
times out.  But they do send <CR><LF>.<CR><LF> on the short messages.

Why this one Vax?  Why the Suns and not the Decs?  What's going on?
-------

I have since seen that the SUNs and DECs are conifgured NOTRAILERS.
Doing an ifconfig on the VAX doesn't give a reference to trailers.

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 15:44:14 GMT
From:      Wesley.R.Palmer@DSB.CPG.CDC.COM
To:        comp.protocols.tcp-ip
Subject:   CDCCENTR BITNET subscriptions

Please remove all subscriptions to users at BITNET node CDCCENTR.  We are no
longer BITNET members.

Wes Palmer
BITNET Tech Rep
Control Data Corporation

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 15:50:04 GMT
From:      dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton")
To:        comp.protocols.tcp-ip
Subject:   TCP/IP <--> IBM network (link?)

> I've just a simple question: a friend of mine, who's working at IBM
> and uses the IBM-network, wonders if there is a way for him to access
> this network we are all using directly from his IBM-terminal (he's
> working in under VM/CMS and MVS/TSO-E and uses IBMtype adresses: NAME
> at NODE)?  How, if the physical link between the two networks actually
> exists, should he write the adresses to be understood by TCP/IP?
>
> Does anybody know anything about this?

IBM has an SMTP mail gateway that allows IBM employees to send and
receive mail to and from the Internet.  SMTP addresses are of the
form:

<IBMuserid>%<IBMnodeid>.IINUS1.IBM.COM    (no MX support)   or
<IBMuserid>@<IBMnodeid>.IINUS1.IBM.COM    (with MX support)

Note that this is a restricted mail gateway running IBM's TCP/IP
Version 2 for VM Secure Mail Gateway code, and IBM employees must first
be authorized before they can use the gateway.

If you have specific questions about the gateway, write:

    postmaster@iinus1.ibm.com

Daniel

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

Daniel M. Barton
TCP/IP Development
IBM Research Triangle Park, NC

Internet:  dmbarton@ralvmm.iinus1.ibm.com
           dmbarton%ralvmm@iinus1.ibm.com

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 16:32:25 GMT
From:      Steven_V_Rosekrans.Roch817@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: LPR as RFC 1179 (was: Is there a protocol for remote printing)

Does anyone within Xerox know of a repository of RCPs.  I'd like to get a copy
of 1179 -- info regarding LPR.

Thanks,
--STEVE

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 16:55:25 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   interest group mail from From: field handling


   Date: Wed, 20 Feb 91 09:02:42 PST
   From: rlg@desktalk.com (Richard L. Gralnik)

   Hi.  Whenever someone posts to an interest group (e.g. tcp-ip), the mail
   the rest of us receive as part of the distribution of that posting shows
   tcp-ip-RELAY@NIC.DDN.MIL in the From: field of the header.  

I think your local mailer is at fault.  As you can see above, your
message arrived here with a proper "From:" field.  The SMTP envelope
did contain tcp-ip-RELAY@nic.ddn.mil, but that should only be used for
bounces (and I appreciate their doing that so I don't see the bounces
when I post :-).  I suspect some local mail delivery system at your
end or your mail user agent is misinterpreting the RFC822 header
and/or the RFC821 envelope.

            __
  /|  /|  /|  \         Michael A. Patton, Network Manager
 / | / | /_|__/         Laboratory for Computer Science
/  |/  |/  |atton       Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 17:55:12 GMT
From:      HANK@VM.BIU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   MANs

I am looking for technical information comparing the various MAN technology
that has emerged over the past year: SONET, DQDB, SMDS, IEEE 802.6,
ANSI X3T9.3, Frame Relay, etc.  I need to possibily give a presentation
next week and would appreciate any postscript graphs or pictures or
any other material that compares the various technologies and where they
stand today.

If anyone has a preliminary RFC or some document discussing all this,
I would love to get a copy of it.

Thanks,
Hank

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 18:54:36 GMT
From:      broehl@watserv1.waterloo.edu (Bernie Roehl)
To:        comp.protocols.tcp-ip,news.admin,comp.mail.misc
Subject:   Re: What Is Difference Between Internet And X.400 Style Names?

In article <39557@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Can someone please explain the difference between X.400 and Internet-style
>names of the form: USER@SITE.DOMAIN?  I had thought that X.400 names
>were of the form /THIS=,/THAT=,/ANDWHATEVER=.

They are.  The standard syntax "user@site.domain" is used throughout the
Internet (and beyond!).  The "/this=,that=" is unique to X.400, which is
part of the OSI spec.


>First, someone told me that the USER@SITE.DOMAIN was an X.400 standard.

They were mistaken.  I much prefer the user@site.domain, since it's shorter
and easier to remember than "/admd=domain,/prmd=site,/name=user".

>Second, I noticed that PSI offers an X.500 service as part of their
>TCP/IP public data network PSInet.  Their
>advertising literature seems to imply that the X.500 database holds 
>addresses of the USER@SITE.DOMAIN type.

It's my understanding that X.500 databases can hold addresses in just
about any format, including physical street addresses.

>are the USER@SITE.DOMAIN style names X.400 or UNIX standards

Neither -- they're standard throughout the entire Internet, which includes
many Unix systems, VMS systems, VM systems, DOS systems, Macintoshes, etc etc.

-- 
	Bernie Roehl, University of Waterloo Electrical Engineering Dept
	Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca
	BangPath: {allegra,decvax,utzoo,clyde}!watmath!sunee!broehl
	Voice:  (519) 885-1211 x 2607 [work]

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 19:27:17 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   UDP 901 info needed


In our IP trace we see UDP protocol port 901 in some datagrams.
However, I can't find anything that tells me what protocol or system this
might be associated with.  Has anyone come across UDP 901 before and
can supply some info on it??

Thanks in advance   -Hal.

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      25 Feb 91 21:41:52 GMT
From:      drubin@prism.poly.edu (Dave Rubin)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   WIN-TCP Problem on 3B2/500

We are running Wollongong's WIN-TCP Version 3.0.1 on a 3B2/500 which is
running System V Release 3.2.1.

We are experiencing several annoying problems, most which have been around
since the earliest versions of WIN-TCP: unstable network connections that
are closed for no reason, daemon's (mostly sendmail) going into bad states,
not accepting connections or producing file-related errors, streams
functions failing on various programs, system crashes due to Kernel MMU
fault, NFS/OpenLook totally broken.  Lately we cannot even get sendmail 
to work at all (although it does work on another almost identical 3B2/500).  
Needless to say, the situation is unacceptable.

I have heard that version 3.2 of WIN-TCP has been released.  Does anyone know
if this latest version fixes any of the problems stated above?  Or do I
need to look into an alternative to these 3B2 systems that can't seem to
behave themselves on the network?

Any help would be appreciated...

--
Dave Rubin
Polytechnic University
Brooklyn, New York

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 00:21:51 GMT
From:      Wesley.R.Palmer@DSB.CPG.CDC.COM
To:        comp.protocols.tcp-ip
Subject:   Whoops

Sorry about that last message.  I pasted in the wrong address.  It was meant
for tcp-ip-request.

Wes Palmer

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 00:55:56 GMT
From:      dlove@NSWC-WO.NAVY.MIL (Donnie Love)
To:        comp.protocols.tcp-ip
Subject:   PSN Questions

Hi,

I have some detailed PSN questions and apologize if this is the wrong group.

1) Is there a limitation to the number of virtual circuits that a PSN will
   allow a particular host for X.25 Standard connections?  I need 64.

2) What are the chances (slim,  probably,  definitely) that I can always get 
   up to 64 virtual circuits when my host requests them?

3) Will a PSN close a virtual circuit which has been idle for a period of time?
   If so,  what is the timer value in the PSN?

Please reply directly to me because I am not on the list, and I'll repost.

-Donnie

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 01:00:28 GMT
From:      finn@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   ICMP Source Quench questions

Marten Terpstra,

	ICMP Source Quench messages may be issued by a gateway when
that gateway becomes heavily loaded (congested).  The congested
gateway picks a message and sends a Source Quench back to that
message's source.  The original message is then discarded by the
gateway.  The idea is that the source will notice this and cut down on
its rate of transmission.  That in turn soon decreases the affected
gateway's congestion.

	The throughput of a gateway is linear as it approaches
overload but can fall to zero quickly.  Consider throughput as the
vertical axis and offered load the horizontal axis and ignore scale.
As load rises from zero, the graph slope is positive to a knee, then
flattish as the gateway's processing limit is closely approached, then
another knee and a rapid descent asymptotically toward zero.  Source
Quench is a way of telling you that the second knee has been reached.
The hope is that if enough sources cut their rates of transmission,
the gateway's operating point moves quickly back to the left of the
catastrophe.

	1) How is the message picked?  Well, it was envisioned that
	whenever a gateway had a queue overflow, the message that
	caused the overflow would be chosen for Source Quench.

	It turns out that many gateways generate them only for SOME
	of the messages that cause a queue overflow and not all.
	That is because no mechanism to force sources to slow down
	in response to receiving a Source Quench was adopted as a
	standard.  However, that may change.

	2) Newer implementations of TCP (incorporating Van Jacobson's
	code) treat the receipt of a Source Quench message as evidence
	of a message lost due to congestion and do slow down for a time
	as a result.  If you run Berkeley UNIX there is a high
	probability that you are running this TCP.

	Research is underway that may place code into source IP modules
	that looks for Source Quench messages.

	3) Will ICMP Source Quench messages cause a network is down
	condition.  No, not by themselves.  If a gateway's routing
	tables indicate that a network is unreachable, only then
	should it send a Network Unreachable version of the ICMP
	Destination Unreachable message.

	This is my understanding.  I hope that this has helped you.

--- ggf

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 03:50:30 GMT
From:      jbev@iscden.jbsys.com ( J B Systems)
To:        comp.protocols.tcp-ip
Subject:   Looking for mil spec archive

I have received a spec which references MS 1777 (IP) and MS 1778 (TCP).
I have the rfc's to tcp and ip, but where can I find an archive for the
mil standards?  Any help would be welcome.

Jim Bevier
jbev@jbsys.com

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 06:58:19 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Re: WIN-TCP Problem on 3B2/500

In article <1991Feb25.214152.27244@prism.poly.edu> drubin@prism.UUCP (Dave Rubin) writes:
>We are running Wollongong's WIN-TCP Version 3.0.1 on a 3B2/500 which is
>running System V Release 3.2.1.
>
>We are experiencing several annoying problems, most which have been around
>since the earliest versions of WIN-TCP: unstable network connections that
>are closed for no reason, daemon's (mostly sendmail) going into bad states,
>not accepting connections or producing file-related errors, streams
>functions failing on various programs, system crashes due to Kernel MMU
>fault, NFS/OpenLook totally broken.  Lately we cannot even get sendmail 
>to work at all (although it does work on another almost identical 3B2/500).  
>Needless to say, the situation is unacceptable.
>[...]

Sigh.  Looks like not much has changed since their version 1.4 for the 3B1.
After some dorking-around with device driver loading, I have managed to find
a configuration that "works" ... at least my sytstems have been up since
November 1990 and I do a lot of 'net trafficking.

HOWEVER: I had to trash a bunch of the "stock" WIN/3B stuff and port over
parts of the networking software suite from 4.3BSD "Tahoe" (as found at
UUNET), and some other 3B1-aficianados have ported over some other stuff.

The WIN/3B sendmail and its daemon  is total garbage ... would fill up the
process table with defunct processes if one so much as sneezed in the same
room, so I tossed it out the window and over the fence to accompany other
bad software ... now I'm worrying the fence may collapse. :-)

A colleague is bringing up a new sendmail (ported from the BSD world) for
the 3B1 and this stuff "should" also work on the 3B2 (but I have NO way of
checking).  The 3B1 archive site is osu-cis (aka cheops.cis.ohio-state.edu)
where you can find some of this stuff as well as in comp.sources.3b1 soon.

If you have all the include files and socket library stuff, you may wish to
try some of the 3B1 ports.  No help possible with NFS, though, since that
feature "level" never made it into the 3B1 product.

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 12:03:23 GMT
From:      sean@noname.UUCP (Sean Mc Grath)
To:        comp.protocols.tcp-ip
Subject:   rcp problems with PC/TCP


We have a network consisting of a bunch of PCs and a Sun machine.  The 
SUN is a SPARC 1+ running SunOS 4.1. The PCs use 3COM ethernet cards and
PC/TCP from FTP.

We use the rcp command provided by PC/TCP from FTP.  Nine times out of
ten the rcp works fine.  By runing ps on the SPARC we see things like :-

karl      2231  0.0  0.0   44    0 ?  IW   10:23   0:00 rcp -f result.s
karl      2230  0.0  0.0   64    0 ?  IW   10:23   0:00 csh -c rcp -f result.s

So it would seem that the rcp caused a csh shell to run the rcp.  The only
funny thing here is that the rcp command takes a -f option.  It is not 
documented under SunOS and seems to cause any rcp to sit around forever.
Anyway the copy works fine.  however from time to time we get a hang on
the PC end doing an rcp.  When this happens ps on the SPARC yields things
like :-

root      2231  0.0  0.0   44    0 ?  IW   10:23   0:00 rcp -f result.s
karl      2230  0.0  0.0   64    0 ?  IW   10:23   0:00 csh -c rcp -f result.s

I.e. it looks as if the spawned rcp command is running as root!  We end
up rebooting the PC and killing off the csh and rcp processes. I've used
trace(1) to watch the system calls that inetd is making to handle our
rcp's but the results are the same irrespective of whether or not the 
PC hangs.  Has anyone any idea what is going on? Thanks in advance.

Sean Mc Grath (sean@fiamass.ie)
12 Clarinda Park North
Dun Laoghaire
Co. Dublin
Ireland.

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 15:01:41 GMT
From:      hta@isolde.Berkeley.EDU (Harald Tveit Alvestrand)
To:        comp.protocols.tcp-ip,news.admin,comp.mail.misc
Subject:   Re: What Is Difference Between Internet And X.400 Style Names?

In article <39557@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes:
                                      I had thought that X.400 names
|> were of the form /THIS=,/THAT=,/ANDWHATEVER=.

You were right. BUT............
1) There exists an RFC called RFC-987 (see also RFC-1148) that specifies how
   to map X.400 addresses to RFC format addresses and the other way round,
   using a big, ugly table called "the RFC-987 mapping table".
   See, for example, the two formats of my address below; they are the SAME
   mailbox.
2) The format /THIS=... is ONE of the possible ways to write an X.400 address
   (you might think that this is nitpicking until you encounter another one :-)
3) X.500 can store anything. We use it today to store (among other things)
   X.400 mailbox names and RFC-822 mailbox names.

Confused? You are not alone!


                   Harald Tveit Alvestrand
Harald.Alvestrand@elab-runit.sintef.no
C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald
+47 7 59 70 94

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 17:26:03 GMT
From:      cage@cbnewsd.att.com (charles.gerlach)
To:        comp.protocols.tcp-ip
Subject:   Re: WIN-TCP Problem on 3B2/500

Folks:

Here we go again.  Trashing products based upon rumors, innuendos, and 
mis-information.  

I empathize with your 3B1 dilemma, but to compare that to the current
AT&T WIN/3B product is wrong.  The 3B2 product was produced by TWG 
approximately 4 years ago as a totally separate product from the 3B2 and 
386 lines.  Since then there have been 3 major releases of the 
other lines (R2.1, R3.0.1/R3.0, and R3.2).  I just checked with AT&T's 
support organization and Release 1.4 is the current 3B1 WIN product.
Its my understanding this product is not under active development,
so R1.4 is all there every will be on the 3B1.

Now to get back to the original question.  Around Christmas, Release 3.2
of WIN/3B and WIN/386 became generally available.  This release consolidates
the available R3.0.1/R3.0 patches and other changes to improve the 
functionality of the products.  Release 1.2 of NFS is also available.

To upgrade from a previous release, please contact your AT&T support
organization or your salesperson.  If they have any problems, tell them to
contact the product manager, Tim Trautman, for information on the upgrade
procedure.

				Chuck Gerlach
				cag@iwlcs.att.com

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 17:37:52 GMT
From:      mjhammel@Kepler.dell.com (Michael J. Hammel)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for source for CUTP

In article <172@rand.mel.cocam.oz.au>, sgs@rand.mel.cocam.oz.au (Stuart
Szabo) writes:
> Does anyone know where I can file request the Clarkson University's
> version of NCSA's telnet and ftp?

        The current version of CUTCP (Clarkson's version of NCSA Telnet)
        is available for FTP from
        omnigate.clarkson.edu:pub/cutcp/2.2-C/tc.cutcp.zoo



Michael J. Hammel        | mjhammel@{Kepler|socrates}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel
#define CUTESAYING "Recycle.  Just do it."

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 18:14:50 GMT
From:      scott@walt.disney.com (Scott Watson)
To:        comp.dcom.lans,comp.protocols.tcpip
Subject:   Laser (optical) bridges for Ethernet

Does anybody out there have any information optical (LASER) 802.3 bridges for
use out of doors??

We have some buildings that we would like to connect, but dread running
cable... any experiences with doing this??? Vendors??

Thanks in advance
-- 
Scott Watson / Walt Disney Imagineering                   scott@walt.disney.com
#ifdef SANE
#include <std_disclaimer.h>
#endif

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 20:30:30 GMT
From:      nieland_t@kahuna.asd-yf.wpafb.af.mil
To:        comp.protocols.tcp-ip
Subject:   How to set up PTR records

I am looking for a good explaination how to set up the PTR records for 
a subnet.   I have the records defined for my subnet and they seem to be
working on my system, but they are not being found on any other system in 
inquire. 

Some of the people I have been asking around here don't have a good idea on 
how to set up the PTR system, so I can use any suggestions.

Ted Nieland				nieland_t@kahuna.asd-yf.wpafb.af.mil
Control Data Corporation		nieland@dayfac.cdc.com
(513) 427-6355				ted@nieland.dayton.oh.us

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 20:55:33 GMT
From:      kwe@BU-IT.BU.EDU (Kent England)
To:        comp.protocols.tcp-ip
Subject:   Compressed Video Transport Requirements Summary


	I didn't get an answer to my question, but I did get some
info on the new ISO standards for compression of still frames and
motion pictures (correlated frame sequences, actually).  Herewith
is what I got, including news on a satellite broadcast system that
is going to use compression to get more channels to the end-user.

	You might want to check out comp.ivideodisc, comp.multimedia,
comp.graphics, rec.video.satellite for more info.

	--Kent

_________________________

From c3!c3.PLA.CA.US!rww@fernwood.mpk.ca.us Wed Feb 13 05:43:16 1991
Date: Wed, 13 Feb 91 02:26:55 PST
From: rww@c3.PLA.CA.US (Richard W. Webb)
To: kwe@bu.edu, barmar@think.com
Subject: Video Compression
Newsgroups: comp.protocols.tcp-ip
Organization: C-Cube Microsystems, San Jose, CA

I have a keen interest in the use of video compression in
a networked environment.  I have collected a number of
articles describing what is available.  I have edited it,
so be forewarned that this is a somewhat biased viewpoint.

JPEG is a Still-image compression technique.  Video is generated
by rapidly displaying consecutive independent frames.

MPEG is a Moving Picture approach that utilizes some of the
similarities that exist between consecutive frames.  It also
includes sound compression and a number of other "system"
features.

Both of these approaches have problems, but, in some sense,
they represent a "optimal" tradeoff between complexity and
quality.  They are also highly parameterized and allow a
broad adjustment in capabilities.

One final note on bandwidth requirements.  Both standards make
allowances for fixed-rate transmission and reception.  This
fixed rate can be updated periodically (at the encoder end)
based, say, on an extimate of network congestion.  The update
rate can be sent, at most, once per frame (60 or 50 frames per
second), but once per 6 or 10 frames is more typical.


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

From: cnh5730@calvin.tamu.edu (Chuck Herrick)
Date: 8 Feb 91 16:57:29 GMT
Organization: Geodynamics Research Institute, Texas A&M University
Lines: 36

JPEG stands for Joint Photographers Engineering Group or some such,
and this is a "standardizing body" which has formalized a 2-d (thus
useful for images) compression/decompression scheme which uses a
modified cosine transform to "do its thing." Right now, the JPEG 
compression sceme is "cutting edge" in the image processing game.

Please note that the JPEG compression is what the folks in the trade
call "lossy"... this means that you may lose at least some information
in the compression process (you might be pretty impressed at the fact
that in many cases, you can't see the difference between an original
image and its compressed-decompressed sibling).

JPEG is neither strictly hardware nor strictly software. A company
called C-Cube is in the process of trying to implement the JPEG
modified cosine transform compression/decompression algorithm in
a chip (i.e. in hardware). When, and if, they succeed, the C-Cube
chip will allow real-time compression, and will be great for real-time
video grabbing. However, the chip is still in process, and until 
someone gets a bug-free JPEG chip to the market, one will need to
implement the JPEG algorithm in software. 


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

>From: jim@newmedia.UUCP (Jim Beveridge)
Newsgroups: comp.ivideodisc,comp.multimedia
Subject: Re: DVI questions
Date: 15 Jan 91 15:09:30 GMT
Organization: New Media Graphics, Billerica, MA

The first chip to do JPEG is from C-Cube, and they are currently only
shipping the still frame version of the chip.  The real time version
is still not available.  Even in compressed form, the bandwidth
required for a full JPEG screen far exceeds the abilities of an
IBM bus to transfer.  (I don't believe it to be a problem for the
Apple NuBus)  JPEG still requires LOTS of data moving around.
To keep track of it, you pretty much require the full resources
of the system to move it off the hard disk and pump it into the
chip fast enough.

Of course, there are ways around this problem with a private
bus and private hard drives, but that is $$$.

The MPEG standard is still under discussion and won't be ready
for at least a year.  Don't expect commercially available MPEG
boards for a couple of years.

DVI is shipping now, but is VERY expensive, particularly for
the production level video that requires that you send a tape
to Intel.  The "home-brew" comperssion that the DVI chips
now do is very grainy and not suitable for production.
The good news is that the production level does not require
almost the entire power of the CPU to keep the picture running.

		Jim

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

From: jandreas@pro-graphics.cts.com (Jason Andreas)
Newsgroups: comp.graphics
Subject: Re: JPEG in VLSI
Date: 26 Jan 91 07:56:21 GMT

  C-Cube MicroSystems
  399-A West Trimble Road
  San Jose, CA 95131
  voice. (408) 944-6300
    fax. (408) 944-6314j
  
   Ask for Jill Milton or Clint Chao.

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

From: ltran@pluton.matrox.com (Linh TRAN)
Newsgroups: comp.graphics
Subject: Re: Animation Standards JPEG
Date: 30 Jan 91 21:49:37 GMT
Organization: Matrox Ltd.

I think MPEG is working on standard for motion picture (animation and sound
included). The MPEG uses fundamentally the same algorithm regarding compression
scheme (it use Discrete Cosine Transform, follow by Quantization of coefficients
and Huffman encoding, for intra frame compression). JPEG mandate is to arrive
at photographic resolution compression.                

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

	Yakov Rekhter of IBM was kind enough to forward this on to me.
-kwe 

____________________________________________

From YAKOV%YKTVMZ@IBM.COM Thu Feb 21 08:23:57 1991
Date: Thu, 21 Feb 91 08:19:27 EST
From: YAKOV@IBM.COM
To: bu-it.bu.edu!kwe@uunet.UU.NET
Subject: compressed video transport requirements

From: andre@rail.mentor (Andre' Hut)
Newsgroups: rec.video.satellite,misc.consumers,misc.consumers.house
Subject: SkyPix cooks up home satellite dish for $700
Message-ID: <ANDRE.91Feb6104313@rail.mentor>
Date: 6 Feb 91 17:43:13 GMT
Sender: Unknown@caeco.UUCP
Organization: /net/rail/home/andre/.organization
Lines: 170


[Reprinted without permission from Electronic Engineering TIMES, Jan. 21, 1991,
by Richard Doherty]

Skypix brings home 80 channels of digitized TV
- ----------------------------------------------
Two-foot dish, set-top digital decoder will be priced at $699

     -24-inch parabolic reflector
     -Cassegrain signal mirror
     -Ten channels of digitally compressed programming
     -Ku-band GaAs downconverter (12Ghz)
     -Infrared Remote
     -Phone connection for credit ordering
     -Stereo, 480-line NTSC video

Las Vegas, Nev. -- The cable TV and backyard satellite dish industries are
girding for a new challenge: the first window-mount home satellite system
available in the U.S.

SkyPix (Kent, Wash.) offered a sneak preview of its compact dish system at
last week's Consumer Electronics Show here and will be on hand at this week's
Satellite Business Communications Association show, also to be held here.  The
startup expects to begin selling systems through retail channels this summer
for about $700.

SkyPix hopes to tap digitial compression technology licensed from Compression
Labs Inc. and advanced Ku-band digital RF modulation to deliver home
programming at a price that will challenge existing cable TV and larger C-band
satellite systems.

Initially, SkyPix will offer up to 80 channels of video programming, but the
system's decoder, a set-top box based on three VLSI chips, will be able to
receive up to 250 channels when more powerful satellites are launched later
this decade.

...

The SkyPix system achieves a data-compression rate of 54 to 1 by using Sun
Microsystems Inc. computers operating at 150 Gflops along with digital-
compression technology licensed from Compression Labs Inc.  With compression,
each channel requires just 2.2 Mbits/second for video and audio, down from a
source data rate of 120 Mbits/s.  Error-correction overhead brings the total
channel requirement to 3 Mbits/s.

The 10 Ku-band channels that are decoded from an RF tuner section that includes
three custom LSI chips.  These chips that the 160 Mhz fo 80 channel data and
extract specific TV images, stereo sound and data.

SkyPix said it will purchase Ku-band GaAs down-converter assemblies from a
number of sources.  These devices change the 12-Ghz incoming satellite signal
into a UHF-band signal that is easier to convey on low-cost coaxial cable.

Once the antenna is aimed at the Hughes SBS-6 satellite, it can be mounted
under the eaves of a house, on its roof or side or on the ground.

At 12-Ghz Ku-band frequencies, satellite antennas usually are subject to one
nagging problem: signal absorption during rainfalls.  In the satellite
industry, signal fades tied to local downpours are referred to as rainouts.
But because of advanced digitial modulation and error-correction technology,
rainouts are not expected to be a problem, according to SkyPix.

The SkyPix system sports a signal reserve of 5db.  In severe cases in which
total signal interruptions occur -- such as when an aircraft flies over the
antenna -- the system will lock into a digitial freeze-frame until the signal
is restored.

In demonstrations viewed by EE Times at the Winter Consumer Electronics Show
last week, most of the video channels shown displayed better than TV-broadcast
quality.  Eight channels were shown operating at one time, fed by a 36-inch
satellite dish.  Image color depth was excellent, and video resolution was
above NTSC standards.

However, during some fast-moving action scenes, there were moments when the
digital compression could not keep up with screen refresh demand.  At these
times, much of the picture turned grainier, as the digital compression tried
to keep up with deltas from one frame to the next.  Overall, the images were
free from RF signal ghosting and coaxial reflection that plague some cable
TV systems.

     -- Richard Doherty
- --
- -------------------------------------------------------------------
Andre' Hut       {mntgfx,utah-cs}!caeco!andre
Mentor Graphics, Suite 300, 5295 South 300 West, Murray, Utah 84107
- -------------------------------------------------------------------

------- End of Forwarded Message

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 22:49:23 GMT
From:      bamakati@athena.mit.edu (Ayisi B. Makatiani)
To:        comp.protocols.tcp-ip
Subject:   problems with snmpd.conf on sun

I compiled MIT's snmpd on a SparcStation 370  after messing around with 
the sources and tried to query it from a Decstation in Ultrix.  To do this, 
I needed snmpd.conf which I copied from Ultrix 4.0 but my queries are not 
replied to by the Sparc.  Does anyone have an idea what I might need to change?
Is there a way to accomplish the same results from SUN OS and MIT snmp as 
compared to MIT snmp and RISC Ultrix?

Thanks in advance.

-ayisi

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      26 Feb 91 23:34:47 GMT
From:      cjs@po.CWRU.Edu (Christopher J. Seline)
To:        alt.censorship,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   CWRU student prevented from teaching how to send ethernet packets


Well...I tried to post the source code to a program I'd written
to a local USENET board here at CWRU...the program demonstrated how to put 
packets onto and take packets off of our campus wide ethernet.

The program was summarily deleted from the board and I was..well...looks
like they threatened me.....anyway....the message follows....please feel
free to write to the the fellow who deleted the program "jag@po.cwru.edu",
and his boss "rkn@po.cwru.edu".

[start included material]

Article #1210 (1213 is last):                                                  
>Newsgroups: cwru.ins.general                                                   
From: jag@po.CWRU.Edu (Jeff Gumpf)                                             
Subject: Interfering with Network Operation                                    
Reply-To: jag@po.CWRU.Edu (Jeff Gumpf)                                         
Date: Tue Feb 26 16:12:28 1991                                                 
                                                                               
                                                                               
We have removed a posting by "cjs" of a program that allows one to send raw    
Ethernet packets.  We suggest that users NOT attempt to use this or any        
similar program to send raw packets on the network.  We remind users that      
any disruption of the network through the use of such programs, intentional    
or not, is considered a violation of the University's ethics policy.           
Anyone found violating that policy will be brought up on charges to the        
appropriate University office.  Such activity will result in disciplinary      
action up to and including dismissal from the institution.                     


Jeff

[end included material]

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 01:41:04 GMT
From:      knauer@cs.uiuc.edu (Rob Knauerhase)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell,alt.censorship
Subject:   Re: CWRU student prevented from teaching how to send ethernet packets

In <1991Feb26.233447.9017@usenet.ins.cwru.edu> cjs@po.CWRU.Edu (Christopher J. Seline) writes:
>Well...I tried to post the source code to a program I'd written
>to a local USENET board here at CWRU...the program demonstrated how to put 
>packets onto and take packets off of our campus wide ethernet.

First, this is a completely non-technical issue so I'm directing followups to
alt.censorship alone.  The character above has apparenly graduated from
firestarting in cwru.ins.general and has discovered the Usenet at large.

Pity.

Chris, there is nothing wrong with the free flow of information.  However, I
think you and I (as well as the cwru.ins.general readership) know that you
didn't post that innocently.  Your post was (my opinion) calculated not to
educate, but to infuriate the Information Network Services people at Case.

>The program was summarily deleted from the board and I was..well...looks
>like they threatened me.....anyway....the message follows....please feel
>free to write to the the fellow who deleted the program "jag@po.cwru.edu",
>and his boss "rkn@po.cwru.edu".

To the readers of comp.protocols.* and others:
    A little knowledge is a dangerous thing, and in that respect this fellow
is dangerous.  His pranks have included instigating personal attacks and
playing with reply-to fields and so forth to harass the staff and directorship
of Information Network Services.  I urge you to ignore his request to further
annoy these people.
    Perhaps alt.censorship is an appropriate place to get into the philosophy
of Computing Ethics policies.  Chris, if you must invent dirty laundry to
hang out, please take it there or keep it in cwru.ins.general...

[I hate disclaimers, but here goes:]  I have no current affiliation with
Case Western Reserve University except as a recent alumnus who keeps current.
Lucky for the human race, few people are spoiled enough to have a fiber
ethernet port in their dorm rooms and not appreciate it; unfortunately, Mr.
Seline doesn't realize that there are responsibilities therewith.

Rob Knauerhase, University of Illinois at Urbana-Champaign
                Department of Computer Science, Gigabit Study Group
knauer@cs.uiuc.edu, rck@ces.cwru.edu, knauer@scivax.lerc.nasa.gov

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 08:32:22 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: Sendmail/SMTP/TCP mystery?

On Mon, 25 Feb 91 15:33:52 GMT William Jaynes said:
>(Deferred: Connection timed out during result wait with uv1.im.med.umich.edu)
>These messages never get delivered.  All attempts fail until they time out and
>are bounced.
>The mailhub is a SunSLC.  The host in question is a Vax running some
>Wollengong TCP-IP/SMTP etc. software.  Up until last week there was not a

A problem we've had seems just faintly related, but might help.
A Ultrix host was repeatedly trying to send to a Sun what appears to be the
end part of a mail item, until the 3-days limit expired.
[ub4b.cs.kuleuven.ac.be to georges.montefiore.ulg.ac.be]
19 lines from a dest queue file w/o control starting (probably spilled here):
           returns the network address and name of all the subscribers. If you
 do not wish
          your name to be available to others  in this fashion, just issue a
 "SET MACMAIL
-- etc..., end of quote --
On each and every attempt, the Sun's sendmail was producing a core dump.
I am in charge of none of those hosts, just routing in between. The problem
may have be started by a longer than usual outage of routers in test.
Yet.

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 10:45:57 GMT
From:      martino@logitek.co.uk (Martin O'Nions)
To:        comp.os.os2.misc,comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: Looking for OS/2 TCP/IP products with RFC 1001/1002

nolet@se-sd.SanDiego.NCR.COM (Jason Nolet) writes:

>Hello OS/2 Users or Programmers!
 
>We are looking for a TCP/IP product on OS/2 which offers a NetBIOS I/F via 
>RFC 1001/1002.   Can you offer any recommendations?  I understand that 
>3Com offers a TCP/IP product for OS/2, but I don't know any details.  I 
>would be most interested in the "more popular" TCP/IP-for-OS/2 products 
>on the market.

The 3Com product does do the job, and provides RFC NetBIOS connectivity for
DOS and OS/2. The latest version (1.2 I think....) has support for 1.21
OS/2, and is supposed to have NetBIOS Name Service Agent capabilities. As
soon as I get round to obtaining/testing a copy internally, I'll post some
more, as this product is of interest for the LM/X <-> LM interconnectivity
market.

If anybody out there has got more info., please post!

Martin

--
DISCLAIMER: All My Own Work (Unless stated otherwise)
--------------------------------------------------------------------------
Martin O'Nions            Logitek Group Support      martino@logitek.co.uk
--------------------------------------------------------------------------
      Auntie did you feel no pain / Falling from that willow tree?
     Could you do it, please again / 'Cos my friend here didn't see.
         (Harry Graham - Ruthless Rhymes for Heartless Homes)

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 12:07:03 GMT
From:      kaba@acdhq.north.de (Kai Bartels)
To:        comp.protocols.tcp-ip
Subject:   do FINs count as 1 like SYNs ?

Hi!
Sending a SYN advances the sequence number by one since it must be ACKed.
A FIN is ACKed, too, so does it advanced the sequence number?
I browsed through RFC761 but found nothing which tells me. :-(

"Is there anybody out there" (who knows about it) ?

greetings, Kai
--------------------
Kai Bartels    | kaba@acdhq.UUCP      | The sound of bombs
Hudemuehler 37 | kaba@acdhq.north.de  | Has given way to childrens cries
D-2800 HB 41   | G14B@DHBRRZ41.BITNET |                      <Fischer-Z>
(0421)34636-13 |g14b@sie.rz.uni-bremen.de|------------------------------
bang: {uunet|pyramid|rutgers}!cbmvax!cbmehq!cbmger!acdhq!kaba

--
--------------------
    ACD Advanced Computer Design GmbH       |acdhq.uucp             |Networks
Dammweg 15     | Tel.: (+49) (0) 421 34636-0|                       |  and
D2800 Bremen 1 | Fax : (+49) (0) 421 3499518|...!cbmvax!cbmger!acdhq| more!

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 13:53:14 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: PSN Questions

Donnie,

> 1) Is there a limitation to the number of virtual circuits that
>    a PSN will allow a particular host for X.25 Standard
>    connections?  I need 64.

Depending on the model PSN, 400 or 1200 (or possibly fewer,
depending on your host's particular port configuration).

> 2) What are the chances (slim,  probably,  definitely) that I
>    can always get up to 64 virtual circuits when my host
>    requests them?

The C/300 PSN can support 1200 simultaneous VCs for all of its
hosts, and the C/30 PSN can support 400.  Individual hosts can
also be limited by configuration to a fewer number of VCs,
although that is not, to my knowledge, common practice on the
MILNET.  On a C/300 PSN, for all practical purposes, your host
should have no problem getting 64 VCs whenever it needs them.  On
a C/30 PSN, it becomes more dependent upon what the other hosts
on the PSN are also doing at the same time.  

> 3) Will a PSN close a virtual circuit which has been idle for a
>    period of time?  If so, what is the timer value in the PSN?

Yes.  The MILNET uses a timer value of 3 minutes.

If you are not sure what model PSN you are using, or have any
problems using the MILNET, I suggest calling the CONUS MILNET
Monitoring Center at (800) 451-7413, or (703) 692-5726 or
692-2268.  They can also be reached by email at
DCA-MMC@DCA-EMS.DCA.MIL .

Regards,
Andy Malis
BBN Communications

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 14:47:31 GMT
From:      cjs@po.CWRU.Edu (Christopher J. Seline)
To:        comp.protocols.tcp-ip
Subject:   Re: CWRU student prevented from teaching how to send ethernet packets


I was originally going to sit out for a few days and take the deserved heat
for bringing this up in an international forum; unfortunently, Rob has libeled
me and I'll take a moment to respond.

In a previous article, knauer@cs.uiuc.edu (Rob Knauerhase) says:
>Chris, there is nothin wrong with the free flow of information.  However, I
>think you and I (as well as the cwru.ins.general readership) know that you
>didn't post that innocently.  Your post was (my opinion) calculated not to
>educate, but to infuriate the Information Network Services people at Case.
Nope.  Please don't tell me what I was thinking.  

I wrote a program that puts packets on ethernet and takes responce packets 
off; the idea that my (or any) program could be modified to send n+1 packets
(swamping our 100M FDDI fiber backbone) scared them; my program didn't do 
that -- but it (And any other program) could be modified to do so.


>    A little knowledge is a dangerous thing, and in that respect this fellow
>is dangerous.  His pranks have included instigating personal attacks and
>playing with reply-to fields and so forth to harass the staff and directorship
>of Information Network Services.  I urge you to ignore his request to further
>annoy these people.
Nope.  I've repeatedly posted (in a local board for discussion) my oppinion
(based on 15 years in the field) that our local computer administration is
inappropriately restricting knowledge and interfering in people's research;
I've also stated that the computer administration is out of touch and that
they innapropriately ignore the advice and comments of faculty/staff/and grad
students (as well as UnderGrads).  I've further compared their management to
how I managed things when I was root (at another fine institution).  



I'D LIKE TO APOLOGIZE TO EVERYONE WHO HAS BEEN BOTHERED BY THE WHOLE
THING.  I INTENDED TO SIT THIS OUT AND TAKE MY DESERVED LUMPS BUT THIS
LIBEL NEEDED A RESPONCE.

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 16:47:30 GMT
From:      wied@birdie.sps.mot.com (Bill Wied)
To:        comp.protocols.tcp-ip
Subject:   Need: Enhanced FTP

I hope I'm posting this in the right news group.

I'm looking for an enhanced version of FTP which will create virtual connections between hosts that are not directly connected, possibly using routing table information on in between hosts.

What I'm thinking of is an enhanced FTP that will first check to see if it can attached directly to the host being sought, if not then it will check it's routing information and FTP to a machine that can connect, possibly through more links, to the machine wanted.

The control connection probably needs to be some virtual pipe but the data connection can either create a virtual connection or use some kind of store and forward mechanism to route it's data to the desired host.

Is there any kind of code already out there??? I would really rather not reinvent the wheel. I would appreciate any help. If I can not find code already existing I will post my solution somewhere.

Please mail me at wied@birdie.sps.mot.com

Thanks in advance!

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 18:14:00 GMT
From:      morrison@herodotus.cs.uiuc.edu (Vance Morrison)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   PCbridge 3C507 support beta testers needed

Hello,

The latest beta version of PCbridge now supports 3COMs Etherlink-16
(3C507) card.  This card is a fast 16bit bus ethernet card designed
for high performance machines.  With it a 12Mhz AT will filter ethernet
packets at 20,000 PPS and forward at 11,000 PPS.  

I have tested the software myself quite a bit, but before I make it
'official' I am hopping to get some other people to test it out too.

Thus I need people who ether have 3c507 cards, or what a high performance
bridge and are thus willing to buy the 3c507s.  

If you fit this category, you can pick up the code and documentation
from accuvax.nwu.edu (129.105.49.1) in pub/pcroute/exp.  The
files you want are pcbridge1.2b.r10.src.tar.Z and pcbridge1.2b.r10.tar.Z.

Vance

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 19:15:53 GMT
From:      david@twg.com (David S. Herron)
To:        comp.protocols.tcp-ip,news.admin,comp.mail.misc
Subject:   Re: What Is Difference Between Internet And X.400 Style Names?

In article <39557@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Can someone please explain the difference between X.400 and Internet-style
>names of the form: USER@SITE.DOMAIN?  I had thought that X.400 names
>were of the form /THIS=,/THAT=,/ANDWHATEVER=.  Recently, two things
>made me question this.  First, someone told me that the USER@SITE.DOMAIN
>was an X.400 standard.  Second, I noticed that PSI offers an X.500
>service as part of their TCP/IP public data network PSInet.  Their
>advertising literature seems to imply that the X.500 database holds 
>addresses of the USER@SITE.DOMAIN type.  I understand that "bang" style
>names are unique to UNIX (a derivative of UUCP), but are the USER@SITE.DOMAIN
>style names X.400 or UNIX standards, and what is the relationship to
>the longer addressing form /THIS=,/ETC=?
>
>Thanks,
>Will Estes        (apple!cup.portal.com!Will)

X.{4,5}00 names for people & mailboxes have (at least) the following attributes:

Country				/C=../
Administrative Domain		/ADMD=.../
Primary Domain			/PRMD=.../
Organization			/O=.../
Organizational Unit		/OU=.../
Surname				/S=.../
Given Name			/G=.../
Common Name			/CN=.../

These are commonly strung together much like what you listed above.
But there isn't a standard for how to represent them on paper.
There also isn't (for X.400 anyway) a given order to these things,
though there is a "natural" order/hierarchy for all but the "OU" attributes.

RFC-987 specifies a translation between that form & RFC-822 domain
addresses which looks like

local-part@OU$bleep.OU$bloop.O$blarp.PRMD$grunch.ADMD$plink.C$frobozz

The equivalent slashy form is

/C=frobozz/ADMD=plink/PRMD=grunch/O=blarp/OU=bloop/OU=bleep/CN=local-part/

So there is something of a mapping.  I am not familiar with the service
that PSI is offering, asking them directly might be useful.

"bang" names are derived from UUCP, but UUCP is no longer unique
to Unix.  Nor has it been for a couple of years now..  I have UUCP
on my Amiga at home & it works fine (gets >1000 characters per
second through a local trailblazer connection!  7.xx MHz 68000 at that ;-)

Suggested reading: RFCs 987, 1138, 1148 and 1154.
	ISO X.4xx & X.5xx standards (available for $$$ from Omnicom
	in Falls Church, VA).
	Marshal Roses "The Open Book" (but only if you can stand long
	digressions into the political maneuvers which networking 
	development has become ... (*sigh*))


		David


-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<-	MS-DOS ... The ultimate computer virus.

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 20:00:33 GMT
From:      mock@watt.support.Corp.Sun.COM (Joseph Mocker)
To:        comp.protocols.tcp-ip
Subject:   ? : TCP Data Integrity

o.k. you TCP Guru's, Heres one for ya!

I've been reading up on the TCP/IP protocol suite and I got a question about
TCP. I can't seem to find out how TCP insures data integrity? in the
TCP Segment header, there is a checksum field, but that seems to be only
for the Header information. So by that, we know that the data got to the
right place, but there is nothing that checksums the data sent. Is this up
to the user program? How is data integrity kept in a TCP transaction?

thanks...joe
--
------------------------------------------------------------------------------
Joe Mocker//USAC//PC-NFS Support :: mock@Corp.Sun.COM :: Sun Microsystems Inc.

  :: there's still lofty dreams  ::  meager desires  ::  still sillyness ::  

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 20:03:07 GMT
From:      sxc@se2.dsto.oz (Stephen Crawley)
To:        comp.protocols.tcp-ip
Subject:   Re: Certified Mail Systems...

PH461A04@VAX1.UMKC.EDU (Guerra de Bureau) writes:
>Regarding a protocol for SMTP certified mail, can anyone suggest
>why the following procedure would not work??
>	1) Local mail system encrypts mail with time-varying key
>	2) Local system forwards mail to remote system
>	3) Remote system delivers (encrypted) mail to designated user
>	4) Designated user requests key from remote system
>	5) Remote system requests key from local system
>	6) Local system indicates to message originator that message
>	   has been received and key requested.
>	7) Local forwards key to remote
>	8) If remote system does note recieve key withing (x) units,
>	   repeats request for (y) tries before informing recipient key
>	   unavailable
>	9) Remote delievers key to remote user/unencrypts original message
 
>The only failure that I see is if a) the remote system requests the
>key from the local system; b) the local system acknowledges the request,
>and c) the anknowlegment(key) never gets back to the remote, and finally
>d) the remote is not able to re-request the key within the designated
>time frame.  Given the increasing network reliability and the decreasing
>network transfer time and a sufficient number of retries/length of
>time before discard this system would seem fairly secure.
 
>Any problems??

If we assume that the network is insecure, I can think of three
security problems with your proposal.

First, a third party (call it "spy") can read mail sent from "local"
to "remote".  Here is how:
   
   When "local" send the encrypted mail message to "remote", "spy" grabs
   a copy of the message.  When "remote" requests the key, "spy" grabs
   the reply message from "local" and uses it to decrypt the message
   at his leasure.

Second, "spy" can fool "local" into thinking that a message has been
delivered when this is not the case.  This is how:

   When "local" tries to send the encrypted mail message to "remote", "spy"
   intercepts it and sends a request to "local" saying "I'm remote; what's 
   the key".  "local" responds with the key, and tells the sender that the
   mail has been delivered.  In fact, the message has black-holed.

Third, "spy" could prevent "remote" from reading mail messages, by grabbing
the messages containing the decryption key.  For ultimate maliciousness,
it could forward the messages with garbled keys!

The root causes of these problems are:
  1)  The decryption key message is sent in clear.  
  2)  Key request and replies cannot be authenticated as coming from
      the right place.


In addition to the security issues above, there are a number of more
mundane problems.

  1) The use of timeouts and timestamps means that the protocol is likely 
     to fail when certified mail and/or key messages are relayed through 
     a slow or flakey mail gateway.

  2) The "local" system has to keep a record of the keys for each certified 
     message sent.  It is not obvious how long this information needs to be 
     kept.

  3) The mail message is sent only once.  If it gets lost, the sender
     loses.  He/she can't distinguish that case from the recipient not
     having read the message.

  4) The notification to the sender of a key request does not tell
     him that the recipient has been able to read the mail.  If
     the decryption key fails to arrive, this will be impossible.


-- Steve


    

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 22:03:37 GMT
From:      duckie@cbnewsj.att.com (john.c.mc millan)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Re: WIN-TCP Problem on 3B2/500

In article <1991Feb25.214152.27244@prism.poly.edu> drubin@prism.UUCP (Dave Rubin) writes:
>We are running Wollongong's WIN-TCP Version 3.0.1 on a 3B2/500 which is
>running System V Release 3.2.1.
:
>I have heard that version 3.2 of WIN-TCP has been released.  Does anyone know
>if this latest version fixes any of the problems stated above?  Or do I
>need to look into an alternative to these 3B2 systems that can't seem to
>behave themselves on the network?

Over the past 3 months our cluster of 3 3B2/700's has upgraded to 
WIN/3B r3.2 and SVR3.2.3.  The improvements have been enormous...
a several-fold reduction in hung processes and crashes.

These machines are cross-mounting [RFS] file systems and pound
the TCP interfaces pretty heavily at times.  There still are
crashes, but we're also running an extensive assembly of
packages, some of which are of local origin, so....  8)


I would STRONGLY recommend upgrading to BOTH SVR3.2.3 and WIN/3Br3.2.

The caveats...

	- Until this a.m., we were running Beta versions of
		WIN/3Br3.2.  I would EXPECT the now-available
		version -- by coincidence loaded onto one of our
		systems this morning -- to be at least as reliable.
		(As pevidence: that system hasn't crashed since!  8)

	- TCP under WIN/3Br3.2 seems to be argumentative with
		earlier releases: rumor has it that as a result
		of fixing a long-term bug regarding window-sizing,
		negotiation-arguments occasionally erupt between
		3.2 systems and earlier ones.  I've seen 99% of
		system CPU disappear for 30 minutes running.

		It's possible the now-available version has
		employed some strategy to counter this, but I'd
		confirm that, or convert all your 3B2's AND 386's
		at one time!  We did convert, and we're quite
		enthusiastic about the result.

	- SVR3.2.3 drops support of the "proc" driver -- 'tho'
		there's a rumor it might return.  (Do you use/
		require 'renice' or 'truss'?)

	- SVR3.2.3 defaults to 2KB logical block File Systems:
		you don't HAVE to convert your existing FS,
		but the KERNEL BUFFERS will be 2KB regardless
		of your FS, so that's 50% wasted RAM in the
		buffers if you don't convert some of your FS
		to 2KB logical blocks.

With pre-apologies for any errors in the above...

John McMillan -- >> jcm@pegasus.att.com << Muttering for self, only

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 22:09:42 GMT
From:      xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead)
To:        comp.protocols.tcp-ip
Subject:   "Forking" with MVS TCP/IP


>I have an a TCP server on MVS that must provide concurrent processing of
>multiple clients.  On UNIX, the approach would be to have the parent
>accept a new connection, fork a child to provide the service, and have
>the parent continue to listen for additional connections.  How does one
>achieve the equivalent of "fork" in MVS under MVS/TCP?
 
>MVS/TCP comes with standard servers like FTP and TELNET.  How do they
>"fork" and is the approach general?  (I do not yet?  have source to
>these so I haven't been able to look myself).
 
>To up the ante, I would prefer this server to be RPC based.  I have had
>good success developing and porting (non-forking) RPC clients and
>servers between UNIX and MVS and would like to reuse some of that code.
>Thanks in advance.

--Jack Fitch@dockmaster.ncsc.mil
I am also interested in how one writes concurrent servers on MVS.  I hope
you have better luck than I did getting answers.  Isn't anyone from IBM
listening?
--
Betty Jo Armstead              SVERDRUP Technology Inc.
21000 Brookpark Rd.Ms 142-2
Nasa Lewis Research Center
Cleveland Ohio 44135           From: xxbja@csduts1.lerc.nasa.gov

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 22:31:48 GMT
From:      blknowle@frodo.JDSSC.DCA.MIL (Brad L. Knowles)
To:        comp.protocols.tcp-ip
Subject:   Re: CWRU student prevented from teaching how to send ethernet packets...

Look Guys,

    This is getting a little tiresome -- if you want to make general
(non-inflamatory) comments on why a particular decision was made, then do so.
If you want to tell us about a program that you wrote that we might find
useful, then do so.  BUT PLEASE KEEP YOUR FLAME WARS OFF THE MAILING LIST(S)!

    And also please refrain from using all caps to make a point -- I did it
above to point out how inapprorpiate it is, but please do not follow my (or
Chris's) example.

    These mailing lists have been set up for one purpose -- so that people who
have questions about a particular subject (in this case TCP-IP protocols) can
do so and expect that very knowledgeable people might be on the mailing lists
and replay to those questions.  It is also here to let people who have
information on a particular subject can tell others about it, even if there has
not been an explicit Rquest For Information on the subject -- if it has
something to do primarily with TCP-IP protocols and their support under any
particular Operating System, then tell us about it or ask us the question.  If
what you have to say has very little to do with TCP-IP, then make your
statement or ask your question elsewhere.

    Rob & Chris, please do not misinterpret this post -- I'm not flaming you
(yet :-| ), I would just like to make sure that we keep the chaff down to a
minimum on this mailing list, and if someone sees your comments without some
sort of response of the sort I have presented here, then they might get the
wrong idea.

    Chris, you had every right to tell us about the availablility of your
program, and the fact that you had tried to make it publicly available, but
politics kept you from doing so.  Neither you nor Rob have the right to say
whether the Univeristy was correct in their decision to keep it off the
publicly available file-space, as that is a matter of opinion.  Also, neither
of you have the right to take public offense at statements of fact -- they are
a matter of fact, and nothing can change that.

    So long as we keep our statements factual, and police ourselves strongly on
matters of opinion, this mailing list will remain useful.  The moment everyone
(myself included) starts making lots of statements of opinion, no matter
whether or not they say that what they have to say is opinion or fact (unless
specifically asked for their opinions, and then they should make sure that what
they have to say is kept very short and sweet), then this mailing list becomes
a vehicle for junk e-mail -- something I'm sure we can all do without.

    Now, I'll get down off my soapbox!

Please do *not* respond!  We have enough statements of opinion in this post as
it is, and I'll just /dev/null private e-mail on this subject anyway!
 _____________________________________________________________________________
| Brad Knowles                 | email: blknowle@frodo.jdssc.dca.mil          |
| Sun System Administrator     |    or: blknowle@wis-cms.dca.mil              |
| DCA/JDSSC/JNSL               | W Phone: (703) 693-5849  ____________________|
| The Pentagon, Room BE685     | Fax:     (703) 693-7329 |Of course, the usual|
| Washington, D.C.  20301-7010 | Autovon:       223-5849 |disclaimers apply.  |
|______________________________|_________________________|____________________|

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 22:48:29 GMT
From:      qureshi@redwood.shell.com (Fawad Qureshi)
To:        comp.protocols.tcp-ip
Subject:   ftp's PC/TCP; Is it NDIS compliant??

I need to know if ftp's PC/TCP is NDIS compliant? In other words, I need
to know exactly what sits between the PC/TCP kernel and the token ring
board, DLC?, IBM's Lan Support Program?, NDIS? Thanx for any info...

Fawad Qureshi
Shell Oil Company
Internet: qureshi@shell.com   &&  qureshi@cs.rpi.edu
Bitnet:   userfwqu@rpitsmts.BITNET

-- 

Fawad Qureshi
Shell Oil Company
(713)795-3772       internet: qureshi@shell.com  &&  qureshif@cs.rpi.edu

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      27 Feb 91 23:40:41 GMT
From:      morrison@herodotus.cs.uiuc.edu (Vance Morrison)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   PCroute bridge-router testers needed

Hello,

I have gotten a version of PCroute to work as a IP bridge-router and 
have done some initial testing on it.  Now I am in need of beta-testers.

Due to problems I don't want to get into, I can only distribute the
binary executables at this time (no source), The source is only slightly
different from the generic PCroute distribution, but there is some
subtlety in its compilation.

I have compiled three versions of this code, one for the WD8013EBT card,
one for the 3COM 3c507 card and one for the WD8003E card.  These
files as well as a simple documentation file that should be enough
to get you going is available from accuvax.nwu.edu (129.105.49.1)
in pub/pcroute/exp/broute.  

So if you are interested in bridge-routing capability, pick up the
software and give it a try.  If you do plan on testing it, or are just
interested in the bridge-routing capability in general please drop
me a message so I know.  

Thanks

Vance

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 06:30:29 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   ? : TCP Data Integrity

The TCP checksum includes the TCP header, the psuedoheader (which
isn't transmitted) and the TCP data. The IP checksum only includes the
IP header.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 06:34:56 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ? : TCP Data Integrity

In article <MOCK.91Feb27120033@watt.support.Corp.Sun.COM> mock@watt.support.Corp.Sun.COM (Joseph Mocker) writes:
>I've been reading up on the TCP/IP protocol suite and I got a question about
>TCP. I can't seem to find out how TCP insures data integrity? in the
>TCP Segment header, there is a checksum field, but that seems to be only
>for the Header information. So by that, we know that the data got to the
>right place, but there is nothing that checksums the data sent. Is this up
>to the user program? How is data integrity kept in a TCP transaction?

You apparently misread.  TCP checksums the entire segment.  UDP's optional
checksum is also of the entire datagram.

IP, however, has a header-only checksum, but IP doesn't claim to ensure
data integrity.  It was designed so that it could be used by applications
that care more about speed than accuracy (e.g. digitized voice).
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 06:42:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   How multiple OOB are hold/mark in socket with only one so_oobmark?

Hi netlanders,
        After reading thru the implementation of socket and TCP/IP from
the book The Design and Implementation of the 4.3BSD OS (published by
Addison-Wesley), I am puzzled of implementing OOB in the socket. Inside
the book (pg 335) the authors describe that multiple OOB messages can be
hold in a protocol if the user specify the SO_OOBINLINE option to force the
OOB data to be placed in the normal receive queue. However, according to the
data structure of socket, so_oobmark is used to mark the offset of the LAST
OOB message from the beginning of the receive queue. My question is:
        How can a so_oobmark to mark different OOB messages? Or does it
means that although many OOB messages can be hold in the receive queue,
only ONE of them can be received using so_oobmark? If so, what is the purpose
of holding multiple messages if we can not differentiate in-band and the
rest OOB data?
        Thanks in advance.

- Beng Hang
  Dept of Information Systems and Computer Science
  National University of Singapore

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 08:21:01 GMT
From:      gday@digigw.digital.co.jp (Gordon Day)
To:        comp.protocols.tcp-ip
Subject:   best cost/performance solutions for site interconnection

Is SLIP the best way to cheaply connect two small (~20 machines each) 
Unix-based lan sites (~30km apart) together? I'm interested in solutions 
which address the requirements of low cost for a internet with low 
performance requirements (typical applications would be SMTP, ~3 
megabytes ftp/week, and occasional Telnet sessions). With this in mind, 
the best thing I have heard about was CSLIP. Is it available to all?  
If so, where can it be obtained from?  Are there better ways?


Cheers,

Gordon Day.


-- 
Gordon

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 13:54:27 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  ? : TCP Data Integrity


 > From tcp-ip-RELAY@NIC.DDN.MIL Thu Feb 28 00:23:15 1991
 > From: sun-barr!newstop!jethro!mock@apple.com  (Joseph Mocker)
 > Organization: Sun Microsystems Inc.
 > Subject: ? : TCP Data Integrity
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > o.k. you TCP Guru's, Heres one for ya!
 > 
 > I've been reading up on the TCP/IP protocol suite and I got a question about
 > TCP. I can't seem to find out how TCP insures data integrity? in the
 > TCP Segment header, there is a checksum field, but that seems to be only
 > for the Header information. So by that, we know that the data got to the
 > right place, but there is nothing that checksums the data sent. Is this up
 > to the user program? How is data integrity kept in a TCP transaction?
 > 
 > thanks...joe
 > --
 > ------------------------------------------------------------------------------
 > Joe Mocker//USAC//PC-NFS Support :: mock@Corp.Sun.COM :: Sun Microsystems Inc.
 > 
 >   :: there's still lofty dreams  ::  meager desires  ::  still sillyness ::  

Joe,
 
From the TCP RFC (RFC793)
 
  Checksum:  16 bits
 
    The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.  If a
    segment contains an odd number of header and text octets to be
                                             ^^^^^^^^
                                             aka the data
    checksummed, the last octet is padded on the right with zeros to
    form a 16 bit word for checksum purposes.  The pad is not
    transmitted as part of the segment.  While computing the checksum,
    the checksum field itself is replaced with zeros.
 
    The checksum also covers a 96 bit pseudo header conceptually

 
[Page 16]
^L

September 1981
                                           Transmission Control Protocol
                                                Functional Specification
 
 

    prefixed to the TCP header.  This pseudo header contains the Source
    Address, the Destination Address, the Protocol, and TCP length.
    This gives the TCP protection against misrouted segments.  This
    information is carried in the Internet Protocol and is transferred
    across the TCP/Network interface in the arguments or results of
    calls by the TCP on the IP.
 
                     +--------+--------+--------+--------+
                     |           Source Address          |
                     +--------+--------+--------+--------+
                     |         Destination Address       |
                     +--------+--------+--------+--------+
                     |  zero  |  PTCL  |    TCP Length   |
                     +--------+--------+--------+--------+
 
      The TCP Length is the TCP header length plus the data length in
      octets (this is not an explicitly transmitted quantity, but is
      computed), and it does not count the 12 octets of the pseudo
      header.

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 13:57:58 GMT
From:      droms@SOL.BUCKNELL.EDU (Ralph E. Droms)
To:        comp.protocols.tcp-ip
Subject:   Re: What Is Difference Between Internet And X.400 Style Names?


      ()

David S. Herron (mips!twg.com!david@apple.com) writes;

   X.{4,5}00 names for people & mailboxes have (at least) the following attributes:

   Country				/C=../
   Administrative Domain		/ADMD=.../
   Primary Domain			/PRMD=.../
   Organization			/O=.../
   Organizational Unit		/OU=.../
   Surname				/S=.../
   Given Name			/G=.../
   Common Name			/CN=.../


Are these attributes required of every X.[45]00 people and mailbox
names, or are they specific to the naming convention chosen by the
NYSERNet White Pages Project (and possibly others)?

- Ralph Droms                 Computer Science Department
  droms@bucknell.edu          323 Dana Engineering
                              Bucknell University
  (717) 524-1145              Lewisburg, PA 17837

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 15:28:33 GMT
From:      allen@b11.ingr.com (John Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: SNA tunneling?

in article <BOB.91Feb19180852@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) says:
> 
> Is anyone working on a standard for IP tunneling over SNA networks?
> That is, given an existing SNA network, and a desire to use it for IP
> transport, is there an equivalent to any of RFCs 1201, 1188, 1171,
> 1149, 1088, 1042, and 877?
> 
> (OK, I just mentioned 1149 to see if you were really watching :-)

Harris - Adacom has TCP/IP over LU6.2.  Requires no software on the
IBM host.  I believe this is a UNIX-based box, it can act as a gateway
to connect remote TCP/IP LANs through an existing IBM Mainframe.
 
-- 
   *    O            .             John E. Allen              *
   *   /\__  ____@__   .  ingr!b23b!allen!jallen@uunet.uu.net *
   *  /\     -|0  ...           (205) 730-8627 (days)         *
   * /  \     ===...... .                                     * 

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 16:06:57 GMT
From:      PMW1@psuvm.psu.edu (Peter M. Weiss)
To:        comp.protocols.tcp-ip
Subject:   Re: SNA tunneling?

In article <1991Feb28.152833.12503@b11.ingr.com>, allen@b11.ingr.com (John
Allen) says:

>in article <BOB.91Feb19180852@volitans.MorningStar.Com>, bob@MorningStar.Com
>(Bob Sutterfield) says:
>>
>> Is anyone working on a standard for IP tunneling over SNA networks?
>> That is, given an existing SNA network, and a desire to use it for IP
>> transport, is there an equivalent to any of RFCs 1201, 1188, 1171,
>> 1149, 1088, 1042, and 877?
>>
>> (OK, I just mentioned 1149 to see if you were really watching :-)
 
>Harris - Adacom has TCP/IP over LU6.2.

As far as I am aware, IBM's TCP/IP For MVS can do this too (except it
uses LU_0 ) and it is called SNALINK.

ref: "TCP/IP For MVS Installation and Connections" form GG24-3412-00

/Pete
--
Peter M. Weiss                   | pmw1 @ PSUADMIN | psuvm.psu.edu|psuvm
31 Shields Bldg - PennState Univ.| ^ affiliated with psuvm.psu.edu|psuvm
University Park, PA USA    16802 | Secrecy is the guardian of bureaucracy

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 16:12:10 GMT
From:      robin@gradient.gradient.com (Dr R.P. Alston)
To:        comp.unix.xenix.sco,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   SCO UNIX, getting the real enet address (48bits)

Although this question relates currently to the SCO UNIX boxes, we are going
to have to answer this same question on more platforms and UNIX's in the
future. Any general suggestions are welcome, this approach has been currently
chosen because the ubiquitous IBM PC architecture does not have any mechanism
to uniquely identify a box (any [34]86 clone walks, talks and smells like any
other clone), unlike other machines such as SUN's that have
unique ID's in ROM.

We have an application that would like to obtain a unique node
identity that is difficult to forge. We would like to be able to
obtain the 48 bit ethernet address for a given board in SCO [34]86
UNIX (3.2) machines which have the lachman tcp-ip installed. Is there
some mechanism in existence that allows a request to convert on a
given machine an internet address to the ethernet address of the board
that supports that INET address? Ideally this would be able
to move forward in the future to other interfaces, and whatever makes
them unique.

We have done this on other machines (SVR4 386) but have had to develop
a driver that goes and mucks with the ARP tables to find the entry
that corresponds to a given INET address, since the arp program, nor
the ioctls associated with arp do not typically provide a way to get
the local ethernet address (after all it knows who it is doesn't it?).
I thought that inquiring here before I go off the deep end again would
be worthwhile.

I was wondering if anyone knows or understands this copy protection
scheme (cpd) that SCO has implemented to know if it provides this
mechanism or not.

Thankyou for any help, save the NET please e-mail responses.

robin

-- 
Dr Robin P. Alston,
Principal Member, Technical Staff,
Gradient Technologies,
robin@gradient.com

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 16:25:23 GMT
From:      JEFF@MITVMA.MIT.EDU (Jeff Harrington)
To:        comp.protocols.tcp-ip
Subject:   Underscores

Hi,
  I've been getting complaints about my SMTP rejecting mail from sites
with a underscore in its host name. If I read RFC 821 correctly, names
may consist of letters, digits, and hyphens. Has this been liberalized
recently?
  The site in question is: its_gate.cc.uow.edu.au

                                 Thanks,
                                   Jeff

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 16:50:50 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for mil spec archive


    I have received a spec which references MS 1777 (IP) and MS 1778 (TCP).
    I have the rfc's to tcp and ip, but where can I find an archive for the
    mil standards?

I don't think the Mil Stds are available in machine-readable form.  Those
two happen to be included in the DDN Protocol Handbook, which you can buy
from the NIC at SRI in Menlo Park, CA or the DTIC in Alexandria, VA.

In any case, you don't want to implement from the Mil Stds for TCP and IP.
They don't specify exactly the same protocol as the RFCs, and furthermore,
they are internally inconsistent in at least a couple of important places
(see RFCs 964 and 963).  Use the HRRFCs (1122 and 1123) to supplement the
basic RFCs (791, 792, 793, etc) and you'll be on the right track.  Note that
the "IP Security" that the DoD may want to buy is *not* what is described
in either Mil Std 1777 or RFC 791.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 16:50:54 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: lsrr, ssrr, & rr options that don't work


    1) Should the packet be tossed?

If the next hop in a Strict Source Route can't be reached directly, drop
it.  Ditto if you can't route towards the next hop in a Loose Source Route.

    2) Should the packet be answered with an ICMP unreachable message?

ICMP Destination Unreachable, Code 5 (Source Route Failed), unless the
failed packet was an ICMP Error Message itself.

       And, if so, how should A handle the Record portion of the option
       list?  A never forwarded it so it never really was routed by it. 

Don't record yourself (I'm guessing), because the information is already
available in the source IP address of the ICMP error.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 17:00:13 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        alt.censorship,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: CWRU student prevented from teaching how to send ethernet packets

[Note: of all the groups the original posting was send to, alt.censorship
is the only really relevant one and I've sent directed all followups there.
It's clearly not a protocol issue.]

cjs@po.CWRU.Edu (Christopher J. Seline) writes:
> Well...I tried to post the source code to a program I'd written to a
> local USENET board here at CWRU...the program demonstrated how to put 
> packets onto and take packets off of our campus wide ethernet.  The
> program was summarily deleted from the board [...]

	I hesitate to get involved in what is obviously an internal policy
decision, but I would tend to agree that the administrators who removed your
posting were perfectly withing their rights to do so.  There is a serious
constitutional issue at stake here, that of free speech.  However, I think
Christopher has slightly misunderstood the issue.  My reasoning goes
something along these lines:

	First, the campus wide ethernet is a shared resource.  Proper
operation of it depends to a large degree on the cooperation of everybody
who uses it.  It is fairly trivial for anybody with the proper knowledge and
a PC (or a Sun workstation running NIT that they have root permission on, or
lots of other things) directly connected to the ethernet to totally disrupt
the entire network.  This is clearly A Bad Thing.  If the university decides
to expell somebody who deliberately puts hand-crafted packets on the network
and messes things up, that sounds fine to me.  It is also besides the point.
The university administration is also exercising head-in-the-sand security
practices if they think removing the article with the "evil" source code
will keep such ethernet tapping/spoofing from happening, but that, too, is
rather besides the point.

	Second, even though you do have the right of free speech, that right
does not extend to using somebody else's communication media to spread your
message, at their expense.  The university paid for the computer on which
you posted your program, and clearly they have a right to decide what is a
valid use of it.  They don't want you to tell other people how to send
random packets onto the ethernet, and (regardless of whether or not they are
wise in wishing this knowledge kept secret) they certainly have the right to
prevent you from using university resources to spread your message.  It
doesn't matter that your tuition dollars may be going to help pay for the
machines; you still don't own them.

	However, let's say you took a slightly different tack.  What if you
printed up your source code and went to a local copy shop and xeroxed, at
your own expense, 1000 copies and handed them out to students?  Let's play
it safe and say you aren't even doing the handing out on university
property; instead you stand just outside of the campus front gate (not
obstructing traffic, etc) on public property.  It would probably be more
useful to make up 1000 floppy disks with your code on it and hand them out,
but that doesn't really change anything.  In that case, if the university
attempted to stop you, I think you would have an extremely strong case that
you are simply exercising your constitutional right to free speech and there
isn't anything they can do about it.  You could go a step further and find
operators of private BBS systems who would be willing to have your code
uploaded to their machines and distribute it that way.  Or, you could buy
your own machine and set up your own BBS.  Or you can stand on a street
corner with a megaphone and read your code to the masses (I'd really like to
see somebody standing on a street corner with a megaphone shouting "Yes,
people, I tell you, all you have to do is open a socket with address family
AF_NIT as root and bind it to /dev/le0 and do a few ioctl's ..."), or hire a
skywriter to draw it in the sky over the computer center.  As long as it
doesn't involve using university resources, they can't do anything to you to
keep you from spreading your message, at your own expense.

	A somewhat different case exists with public service announcements
on TV.  In that case, you need a license from the FCC to broadcast, and the
number of TV channels that can be allocated in a given area is limited; even
if you were willing and able to spend the considerable sum of money needed
to set up your own TV transmitter, it wouldn't do you any good.  Since that
is the case, as a condition of granting a license to a station, the FCC
requires that the station allow a certain amout of public service use.  You
could try to make a case, I suppose, that the campus-wide ethernet is a
monopoly similar to a TV channel allocation, and thus the university is
required to allow you to post your code as a "public service" but I think
the case would be extremely weak indeed and you wouldn't get very far with
it, especially considering how easy it is for you to find other distribution
methods that are essentially just as good and would cost you a relatively
modest sum of money.  You could set up a BBS in your dorm room (or, better
yet, your off-campus apartment) to distribute the code and I suspect that
anybody who could make use of it would have the equipment and know-how to
download it.  Total outlay to you for a cheap PC and a modem could easily be
under $1000; a lot of money for a college student, I guess, but lots of
undergraduates CS majors do seem to have their own PCs (many schools even
require it, CS major or not).

	Please note that I am *not* advocating that you send random packets
on the ethernet, or that you distribute your code to other people so they
can do so.  I think doing either would be an extremely irresponsible thing
to do.  However, there is an important constitutional issue here; namely
that you do have the right to distribute information which other people find
distasteful, as long as you do it at your own expense.  The fine line which
many people seem to misunderstand, however, is that you *don't* have the
right to force other people to distribute it for you.  Free speech doesn't
mean that the New York Times has to accept my full-page ad esposing my
personal opinion that Saddam Hussain is a nice guy if they don't want to, it
just means that I can, if I choose, buy my own printing press and paper and
ink and go into the newspaper business myself, if that's the only way I can
find to get my ad into print.

	In my college days, the big censorship deal was whether the ChemE
students who wanted to do free paraquat testing (as a public service) should
be allowed to advertise their services in the college newspaper.  Paraquat,
for those who havn't heard of it, was something (a herbicide?) that was once
sprayed on marijuana fields by the drug control folks; smoking paraquat
tainted pot was very bad for your health.  I don't think the idea ever got
off the ground, so the issue was a moot point.  Among other things, they
probably were planning on using the school chem labs to do the testing,
which, of course, the school was within their rights to disallow.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 17:05:33 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re:  ftp's PC/TCP; Is it NDIS compliant??


	
  I need to know if ftp's PC/TCP is NDIS compliant? In other words, I need
  to know exactly what sits between the PC/TCP kernel and the token ring
  board, DLC?, IBM's Lan Support Program?, NDIS? Thanx for any info...
	
Our PC/TCP is available for a variety of environments. Usually, people
running PC/TCP over Token Ring use an IBM ASI driver (e.g. tokreui,
the LAN Support Program) and our PC-219, but you could also get our
PC-210 and use it over an NDIS driver or a Class 3 (802.5) packet driver. 
In addition, we have direct support, with our own drivers, for several
Proteon PROnet cards.

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 17:07:12 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: SNA tunneling?

In article <1991Feb28.152833.12503@b11.ingr.com>, allen@b11.ingr.com (John Allen) says:
   in article <BOB.91Feb19180852@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) says:
      Is anyone working on a standard for IP tunneling over SNA
      networks?

   Harris - Adacom has TCP/IP over LU6.2...

and in private mail:

   Date: Tue, 19 Feb 91 18:21:28 CST
   From: David Boyes <dboyes@brazos.rice.edu>
   
   The IBM TCP/IP for VM package already does this quite nicely. The
   SNALNK component of the software opens a LU0...


   From: Paul Sergeant <paulus@convex.mitek.com>
   Date: Mon, 25 Feb 91 10:09:33 CST
   
   IBM's ... SNALINK ... for MVS and VM.  This connects TCP/IP
   networks using LU0 connections.  Each IBM mainframe must have
   TCP/IP installed for this to work.
   
   OpenConnect Systems ... an IP level router ... called OCIR,
   encapsulates TCP/IP or UDP/IP in an LU 6.2 frame ... OCIR also can
   emulate IBM's SNALINK, so it can connect via IBM's TCP/IP.
   

   Date: Tue, 26 Feb 91 17:56:51 EST
   From: rlg@ida.org (Randy garrett)
   
   I also found a company called Brixton that has a card for the Sun
   that translates IP into something understandable to a 3745...

There are several implementations, using disparate schemes, but no
standards.  The schemes about which there's any detail use either LU0
or LU6.2 transports, as expected.  But unless one explicitly emulates
another, there's no guarantee that their encapsulation methods will
interoperate, even if they picked the same LU transport.  Caveat
Emptor!

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 17:24:33 GMT
From:      cws@FTP.COM (Cris Shuldiner)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp's PC/TCP; Is it NDIS compliant??


    Date: 27 Feb 91 22:48:29 GMT
    From: nuchat!shell!redwood!qureshi@uunet.uu.net  (Fawad Qureshi)
    Subject: ftp's PC/TCP; Is it NDIS compliant??
    
    I need to know if ftp's PC/TCP is NDIS compliant? In other words, I need
    to know exactly what sits between the PC/TCP kernel and the token ring
    board, DLC?, IBM's Lan Support Program?, NDIS? Thanx for any info...
    
    Fawad Qureshi


Yes, our PC-210 part number of PC/TCP works with NDIS.  If you wish
to run on Token Ring the you can use this with Token Ring NDIS
drivers.  Alternatively, you can use our PC-219 part number to work
with the IBM Lan Support Program (or other ASI's).

Cris Shuldiner						Product Support
cws@ftp.com						FTP Software, Inc.
Ph: (617) 246-2920					Fax: (617) 245-7943
---------------------------------------------------------------------------
"Nobody told me there'd be days like these. Strange Days Indeed."
							-John Lennon
---------------------------------------------------------------------------

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 18:01:33 GMT
From:      tb@Materna.DE (Torsten Beyer)
To:        comp.protocols.tcp-ip
Subject:   SNMP Products

Hi Everybody,

I'm interested in SNMP-products that will be demonstrated at next months
CeBIT computer show in Hannover/Germany. Any hints on company exhibiting
their SNMP product in Hannover are greatly appreciated...


			ciao
				-Torsten
--
Torsten Beyer                      e-mail : tb@Materna.DE
Dr. Materna GmbH		   VOX    : +49 231 5599 225
Vosskuhle 37			   FAX    : +49 231 5599 100
D-4600 Dortmund 1,  West Germany

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 18:37:14 GMT
From:      cs175111@csusac.ecs.csus.edu (Steven Little)
To:        comp.protocols.tcp-ip
Subject:   Need a compact Ethernet driver for AT&T 7300


 	I am currently working on a project to connect an AT&T 7300
to a host via an Ethernet cable.  The problem I'm having is that
the ROM space in the 7300 is very small.  
	What I need is a reduced tcp-ip or a tiny tcp-ip to handle
this problem.  I thank anyone who can help me with my problem in advance.

	  Send response to cs175111@csusac.ecs.csus.edu 

	This is the first time I have posted on this newsnet so sorry if
I make some errors.

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 18:59:30 GMT
From:      nolet@cns.SanDiego.NCR.COM (Jason Nolet)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP via Token Ring


Netters:

Has anyone out there implemented the TCP/IP protocols over a Token
Ring LAN?  If so, is there an RFC is can turn to (1042 maybe)?

I would be very interested in the names of any vendors which offer
such as product.

Thanks for your help!

/******************************************************/
/* Jason Nolet                                        */
/* Network Products Div. - San Diego, NCR Corporation */
/* email:  Jason.Nolet@SanDiego.NCR.COM               */
/* Phone:  (619) 578-9000  Fax: (619) 963-5705        */
/******************************************************/

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 21:34:53 GMT
From:      kdenning@pcserver2.naitc.com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Time server (Internet-style); anyone got freely distributable source?

Hi!

I'm looking for the source code to the Internet time server program.  The
MIPS systems we have here have a thing called "timed", and the Suns have 
"rdate".  Both of these appear to be proprietary to their respective
machines.

I would like to be able to synchronize all the clocks in our domain using
this.... including PCs.  Beame and Whiteside has the ability to query one on
demand, if I can find the Unix-side code!

Thanks in advance for pointers or code!

--
Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285
kdenning@nis.naitc.com

"The most dangerous command on any computer is the carriage return."
Disclaimer:  The opinions here are solely mine and may or may not reflect
  	     those of the company.

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 22:00:29 GMT
From:      bruno@sdcc10.ucsd.edu (Bruce W. Mohler)
To:        comp.protocols.tcp-ip,comp.sources.wanted,comp.unix.admin
Subject:   whois server source

Does anyone know of any freely available source to a whois
server?  I'm aware of the ones that are available from UC Davis
and U Virginia.  I'm aware of the "client" program that is part
of the BSD 4.3 distribution.  All pointers welcome!

Thanks, in advance.

Bruce

-- 
Bruce W. Mohler
Systems Programmer (aka Staff Analyst)
bruno@sdcc10.ucsd.edu
voice: 619-586-2218

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      28 Feb 91 22:53:58 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Does BSD Know Packets?


A few toss-up questions:

Does anyone have data showing the 'hit rate' of pulling as much data
as possible into a retransmission? Put another way, how often does a
series of packets get lost vs a single packet? I think the
effectiveness is rather low, but am not sure.

This comes out of some 'deep-thought' I've been trying to do
concerning BSD's implementing the congestion control packet windows as
byte windows - presumeably because BSD does not have a concept of a
'packet rtxq' in favor of a 'bytes rtxq' (Does that change in 4.4?)

In another life ;-) I worked-on a system where there was a 'packet
rtxq', which would seem to more purely implement a packet congestion
window scheme (primarily because it knows how many 'packets' are out
there and doesn't estimate it using MSS's). The trade-off (which I
think was unconscious) was that there was no 'pulling-up' of data into
retransissions. If a 10 byte packet was lost, then a 10 byte packet
would be retransmitted. It also seems to have more frequently achieved
exponential growth in packet window, whereas BSD seems to effectively
get linear (one MSS per ACK packet - or does that change too?)

Hence my question as to the effectiveness of pulling-up data into rtxs.

There are other questions, but I'll float these first.

rick jones

END OF DOCUMENT