HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Telnet option codes
Date: 18 Aug 92 20:48:49 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <LAH.92Aug18112511@genesis.unh.edu> lah@unh.edu (Lance A. Hartford) writes:
>	Is there a way to get a list of all telnet option codes, without
>searching through the RFC's? Thanks

The usual answer to "how do I get a list of...." questions is to look in
the Assigned Numbers RFC.  And indeed, it's the correct answer in this
case.  The latest Assigned Numbers is RFC 1340, I believe.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: gsa@easyaspi.udev.cdc.com (gary s anderson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Raw IP
Date: 14 Aug 92 15:46:02 GMT
Reply-To: gsa@easyaspi.udev.cdc.com (gary s anderson)

In article <1992Aug14.120245.8688@news.uit.no>, rune@regina.itek.norut.no (Rune Hamnvik (Stud IT)) writes:
|> Hello
|> We are using Berkeley sockets and we wish for some reason to use
|> raw sockets, but we have a problem. We can not send packets greater
|> than about 1500 - 2000 bytes. Why is that ?
|> Does the protocol spesify this or is it only the implementation that
|> has this limitation ? 
|> I have read that IP can do fragmentation and that the maximum
|> size of an IP datagram is 65536 bytes. Is this true ?
|> 
|> Can someone please help us ?
|> 
|> Rune Hamnvik

Here are two possible reasons:

1)	The socket send and/or receive buffers are not large enough.
	A nominal value used in BSD code is 2048 bytes.  You can use
	the getsockopt to check the sizes and the setsockopt to
	change the sizes.

2)	You are going between network solutions and the don't fragment
	option is set (e.g. when going from FDDI to Ethernet).  Unless
	you have control over the IP headers you may be SOL (NOTE - if
	you're lucky you might be able to configure the FDDI MTU size).

My guess is that issue "1" is the problem, however, one is always 
humbled by new findings.
Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans.fddi
From: mogul@pa.dec.com (Jeffrey Mogul)
Subject: Re: IP-multicast for FDDI?
Organization: DEC Western Research
Date: Sat, 22 Aug 92 01:46:56 GMT

In article <1992Aug19.073226.4812@news.uit.no> lars@itek.norut.no (Lars Vognild) writes:
>
>Does anyone know of an implementation for FDDI of Deering's IP-multicast?
>
>Im running Ultrix 4.2 on a DECStation 5000/200 with DEC's FDDI cards

Try looking at the files in 
pescadero.stanford.edu:/vtmp-ip/*ultrix*

To use this you may need an Ultrix source license (which is fairly cheap for
educational institutions); or maybe not.  I have NOT used this code myself.

The FDDI driver in Ultrix probably supports multicasting at the link
layer; it's the IP code that needs to be patched.

-Jeff
From: joachimf@norisc.erls01.siemens.de (Joachim Feld)
Newsgroups: comp.protocols.tcp-ip
Subject: HELP: Need AX25 driver for AT&T Sys V Rel 4.0
Date: 19 Aug 92 12:32:31 GMT
X-Newsreader: Tin 1.1 PL5

AX25 is the X25 protocol adapted for amateur radio to have TCP/IP
connections over amateur radio stations. 

Please contact via e-mail, I will summarize all answers to the net.
 

Thanks

Joachim DL8NBS

P.S: I don't need it for the company !!!

--
------------------------------------------------------------------------------
Joachim  Feld			email:  joachimf@norisc.erls01.siemens.de
					SIEMENS AG AUT 922B
------------------------------------------------------------------------------
Newsgroups: comp.protocols.tcp-ip
From: dboyes@is.rice.edu (David E Boyes)
Subject: Re: profs / vm/ forwarding mail
Organization: Rice University
Date: Tue, 18 Aug 1992 15:08:30 GMT

In article <BsxGMq.M34@wm-mercer.ca> carrollj@wm-mercer.ca (Jim Carroll) writes:
>In article <1992Aug10.185212.15@nmrdc1.nmrdc.nnmc.navy.mil> dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small) writes:
>>What I need is a method on our KNET equiped VM system, is to be able to
>>forward the mail to another stmp hosts (If it makes it easier, the
>>id can be the same, but the address will be different)

>1. First, become an expert in sendmail.	:-)

It's not nearly that complicated. Assuming that KNET has some
kind of feature similar to the MAILER keyword in IBM's SMTP
implementation, all you need to do is install a recent version of
the Columbia/Princeton VM MAILER code (available on the most
recent VM Workshop tapes or from LISTSERV@PUCC.PRINCETON.EDU),
and configure KNET to send all incoming mail through the MAILER
DVM. 

The MAILER record in the IBM SMTP implementation tells the SMTP
machine to send all incoming messages to the identified virtual
machine for final delivery. MAILER gets them, looks up the
userid, and then if forwarding is necessary, regenerates the
BSMTP header and reprocesses it -- presto, remote delivery.

There is no charge for the Columbia/Princeton MAILER code, and I
strongly recommend it to any VM sites.

>I suppose one loose alternative (you'll have to test it, of course)
>is to add aliases on all systems, pointing out the proper hosts for
>the given mail in question.


This is rather unwieldy, given large numbers of users and hosts.
The other method is user-controllable.

>Jim Carroll - carrollj@wm-mercer.ca


-- 
David Boyes
dboyes@rice.edu
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: getting RFCs
Date: 17 Aug 1992 18:21:46 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <JRAJA.92Aug17123039@vipunen.hut.fi> jraja@vipunen.hut.fi (Jarno Tapio Rajahalme) writes:
>nic.ddn.mil carries the rfc's (anonymous ftp). By the way, rfc's are 
>allways 'latest copyes', since once rfc is published it is never
>changed afterwards.

This is mostly true.  However, the rfc-index.txt file is updated
frequently; if you have an old version of this, you might be directed to
read an old version of an RFC (for instance, unless you have a recent
rfc-index.txt you'll think that "Assigned Numbers" is RFC 1060, not RFC
1340).

Also, the documents in the FYI series are updated with the same numbers.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.protocols.tcp-ip
From: russ@meaddata.com (Russ Rahn)
Subject: Request for Help on TCP problem
Keywords: retransmit, window
Followup-To: comp.protocols.tcp-ip 
Organization: Mead Data Central, Dayton OH
Date: Fri, 14 Aug 1992 14:31:57 GMT
Distribution: usa


I have been witnessing from time to time, a series of events that I
feel is improper.  I am asking for help from you gurus on the net so
that I can determine (1) if there is a problem, and (2) who has the
problem.  The following is a description of what I see:

We have a protocol converter that takes frames from an X.25 cloud and
converts them to TCP-IP packets and sends them to our PC.  It does the
opposite with TCP-IP frames generated by our PC.

Let's pick up the action with everything running fine.  Our PC is all
caught up and has just acked with an ack value (for the sake of this
discussion) of 0, and gave a windowsize of 512.  The converter sends
a packet to our PC with seq# 0.  For one reason or another, this frame
is missed by the PC.  The converter sends the next frame with seq#
128.  This is what I would have expected.  The PC responds with an ack
message with ack = 0.  Again this is what I would have expected, but
this is the point where reality begins to deviate from my
expectations.

The converter then sends a packet with seq# 256.  The PC acks 0.  The
converter sends the packet seq# 384 with a length of 128.  This fills
our window.  The PC acks 0.  Since our window is full, the converter
listens to the PC this time and retransmits the packet with seq# 0.  The
PC gets it and acks 128.  Our window is no longer full, since it has
just slid over 128 bytes.  The converter then sends a packet with seq#
512.  The PC is forced to ack at 128.  The window is full again, so
the converter listens and resends packet seq# 128.  The window slides
and this pattern continues.

I thought that I had read that if you receive an ack for less than you
had already sent, then you should forget all that was sent after the
ack point and retransmit from that point on.  If you don't receive an
ack, then you should continue sending more and more new packets until
you either fill the given window (flow control) or you eventually get
an ack telling you what to do.

Is this right?  Or should the PC have been saving all of the frames
that were provided after the ack value it gave (those that filled the
window) so that when the converter got around to retransmitting the
missed packet (seq# 0), the PC could have then acked the whole window?

You can see how the current action is putting a delay in our
processing while the window gets filled, and then slows processing
after that by requiring so many packets to deliver just one.

Please E-Mail with any response as I don't get to read the News very
often.  Also, if you would like to help, but I haven't made my
question clear enough, please drop me a line and I'll try to describe
the situation better.

Thanks in advance!

Russ
  
russ@meaddata.com


Newsgroups: comp.protocols.tcp-ip
From: fff@microplex.com (Fred Fierling)
Subject: TFTP Broadcasts
Organization: Microplex Systems Ltd
Distribution: na
Date: Tue, 18 Aug 1992 05:07:59 GMT

In RFC 906 (Bootstrap loading using TFTP) it is written:

   [**]  Editor's Note:  While there is no standard for an Internet wide
        broadcast or multicast address, it is strongly recommended that
        the "all ones" local part of the Internet address be used to
        indicate a broadcast in a particular network.  That is, in class...

How pervasive is this type of broadcasting?  Anyone care to hazard a guess
as to what percentage of systems support it?  Are there any big time vendors
that do NOT support it?
-- 
Fred Fierling    fff@microplex.com       Tel: 604 875-1461   Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC   V5T 1A7,  Canada
From: ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: What are the Pros/Cons of Multi-protocol routing?
Date: 21 Aug 92 18:03:55 GMT
Distribution: usa

The disadvantages to running a mutli-protocol network become more
apparent the larger it gets.  The level of sophistication of the routing
code for one protocol in a router versus another becomes clear as you
stress the box.  The result CAN be that you take out a portion of your
network due to a malfunction in a protocol.  Mind you, IP is just as
much a possibility for this as any other.

You also have to know more about these other protocols so that you can
debug them.

I'm not saying you shouldn't do it:  just recognize you are running
parallel networks that just happen to use the same physical facilities. 
And I certainly wouldn't advocate tunneling.  That's always been a bad
idea.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689
Newsgroups: comp.protocols.tcp-ip
From: nduong@rhea.trl.OZ.AU (Nguyen Duong - Integrated Communication Services)
Subject: How to drive a Crynwr packet driver?
Keywords: packet driver
Organization: Telecom Research Labs, Melbourne, Australia
Date: Wed, 12 Aug 1992 23:52:07 GMT

I've down loaded the Crynwr packet driver collection but have no idea
how to drive it. Can somebody post or email some clue? Surely there must
be some document somewhere that specifies the services of a packet
driver (under DOS)? For realtime reason I've have to drive the packet driver
directly from my program. BTW, can I use the same driver under OS/2? If
not how do I go about using a packet driver (or such like) under OS/2?

Thanks very much for any help you could give.
nduong@trl.oz.AU
Telecom Australia Research Laboratories.
From: hofer@rchland.vnet.ibm.com (Kent Hofer)
Newsgroups: comp.protocols.tcp-ip
Subject: ioctl() questions
Date: 18 Aug 92 01:07:04 GMT
Organization: IBM Rochester
Disclaimer: This posting represents the poster's views, not necessarily those of IBM


Could anyone please answer the following questions for me:

ioctl() networking commands are grouped into 4 categories in the Steven's book: 
  - file
  - socket
  - routine
  - interface

FILE CATEGORY:

1) what address family must be used?
  - file - I assume this can relate to any address family.  Are all supported
      for AF_UNIX and AF_INET?
 
2) what socket type must be used? I assume that it makes no difference, correct?
 
SOCKET CATEGORY:

1) SIOCATMARK isn't supported for AF_UNIX, right?  Otherwise process group options should be universal, right?

2) Again, socket type makes no difference, right?

3) What are high water marks and low water marks, and why are they here if they are not implemented?  How do they relate to the socket options SO_RCVLOWAT and SO_SNDLOWAT?  Was the SIOCSLOWAT supposed to set both the send and receive side low water marks (whatever they are) or was it intended for just one side?  


ROUTING CATEGORY:

1) Are there more protocol stacks than AF_INET that use these ioctls()?

2) What socket_type is required to use these?  (Rephrased - can I add a TCP
route using a stream socket, a datagram socket, and/or a raw socket?)

INTERFACE CATEGORY:

1) Same questions - what address family and type are required for this? 


Thanks for any answers to any of the questions!!!
  

Kent Hofer    hofer@rchland.vnet.ibm.com  

(my opinions are my own and have nothing to do with my employer)
From: THOMASG@epx.cis.umn.edu (ThomasD.Gasser)
Newsgroups: comp.protocols.tcp-ip
Subject: POP Server on IBM-PC
Date: 13 Aug 92 20:32:57 GMT
Organization: Department of Neurosurgery, University of Minnesota

Hello all,

I have heard that it is possible to run a PC as a POP server maybe using 
KA9Q.  I would like to use an old IBM PC connected to ethernet and a Novell 
3.11 server.  

Any ideas?



*********************************************************************
*  Thomas D. Gasser                                                 *
*  Department of Neurosurgery                *******     ******     *
*  University of Minnesota                    ***  *** *** ***      *
*  (612) 624-4427                             ***   *****  ***      *
*  E-Mail:  THOMASG@EPX.CIS.UMN.EDU          *****        *****     *
*                                                                   *
*********************************************************************
Newsgroups: comp.protocols.tcp-ip
From: macauley@bnr.ca (John MacAuley)
Subject: Maximum udp message size.
Reply-To: macauley@bnr.ca (John MacAuley)
Organization: Bell-Northern Research Ltd.
Date: Thu, 13 Aug 92 19:52:08 GMT


I need to know the maximum allowable size of user data
in a udp message.  The sendto man page on my hp specifies
a maximum value of 9216 bytes for hp series 300 and 800.

I can't seem to find the same information for Sun3, and
Sun4 Sparc.  Does anyone know the maximum value?  How
about on other platforms?

Besides sending packets of increasing size until sento
returns EMSGSIZE, is there any way to find this information
in header files?  I will need to find a common maximum for
a number of platforms and would like to save time searching
for the values.

Thank you in advance,

John.
Newsgroups: comp.protocols.tcp-ip
From: ddurbin@is.rpslmc.edu (Dave Durbin)
Subject: 3172 Help
Organization: Rush Presbyterian-St. Lukes Medical Center
Distribution: usa
Date: Fri, 21 Aug 1992 17:14:32 GMT

Some colleagues (sp?) of mine need help with the following:

1) Printing from a 3090 via TCP/IP over a 3172.
2) File transfer (FTP) from MUSIC and CMS via TCP and a 3172.


Any help/experience/war stories are greatly appreciated!

Thanks in advance!

Dave Durbin
Advanced Technology Center
Rush-Presbyterian-St. Luke's Medical Center
(who needs a .sig)
From: oberman@ptavv.llnl.gov
Newsgroups: comp.protocols.tcp-ip
Subject: Re: What are the Pros/Cons of Multi-protocol routing?
Date: 21 Aug 92 20:48:12 GMT
Distribution: usa

In article <l9aeprINNsg0@noc.near.net>, kwe@noc.near.net (Kent England) writes:
> In article <86673@netnews.upenn.edu> Anthony Olejnik writes:
>>
>>Currently we have a pure IP only backbone.
>>
>>What are some of the advantages/disadvantages of keeping the
>>backbone pure (with only IP)?
>>
>>What are the advantages/disadvantages of tunnelling the other
>>protocols (AppleTalk/IPX/DecNet) within IP?
>>
>>Any comments would be *GREATLY* appreciated.
> 
> TCP/IP has more sophisticated routing protocols than many of the other
> internet protocols you can run, and it and OSI are the only protocols
> suitable for a public internet.
> 
> The disadvantage of a single protocol backbone is tunneling everything
> else when routing is easier.
> 
> But tunneling is sometimes necessary such as for getting AppleTalk across
> the Internet, for source routed bridging across a complex WAN, or for
> tunneling SDLC.
> 
> Don't underestimate the complexity of supporting additional protocols
> whether tunneled or routed.  Make sure you have enough features and
> filters to control them.  But if they are important enough to your
> situation, then by all means support them.

I have a problem with oversimplifying anything. And this is way oversimplified.

First, how big a backbone is involved? For a small backbone of a couple
thousand systems, routing all of the mentioned protocols is no problem.
AppleTalk and IPX don't scale well, though, for big nets. And all routed
protocols must be centrally administered to avoid addressing conflicts.

AppleTalk should be AppleTalk Phase 2. Phase 1 sends out to much overhead on a
large net. And don't even thing about large scale tunnelling of AppleTalk. The
RTMP will kill you. Routing can work to a limited extent, though.

DECnet is quite suitable for wide area routing. It was designed for it and is
generally much easier to manage than even IP. Many regionals and two of the
three national backbones in the US carry DECnet quite well with a global DECnet
internet of at least 20K nodes. (It's probably much larger, but it's hard to
keep track.) But to join the global DECnet you must get addresses from a
central authority, just like with IP.

I guess I'd say the multi-protocol routing is much better than tunnelling in
most cases. But you have to understand the protocols and how the operate on
things like slow serial lines and with slow propagation. IP, DECnet, and OSI
are well suited to large networks. AppleTalk and IPX are OK for smaller nets,
but not to anything like the size of the Internet.

I might also mention that DECnet has only 16 bits of address, so you have to
deal with that when the net gets big. IP will have this problem shortly. At up
to 160 bits, OSI is OK for a while.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 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.
Newsgroups: comp.protocols.tcp-ip
From: berg@physik.tu-muenchen.de (Stephen R. van den Berg)
Subject: Extending IP-numbers
Originator: berg@tabaqui
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: Mon, 17 Aug 92 15:22:46 GMT

I heard some rumors about several proposals being already on the table
concerning extending the current 4-byte IP-addresses.

Could anyone knowledgeable disclose some specifics about these proposals?
(Or some pointers on where to look for more info?)

Thanks.
-- 
Sincerely,                                  berg@pool.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

"Be spontaneous!"
Newsgroups: comp.protocols.tcp-ip,comp.unix.programmer
From: dsiebert@icaen.uiowa.edu (Doug Siebert)
Subject: Questions regarding OOB data and telnet/rlogin
Date: Tue, 18 Aug 1992 22:41:01 GMT
Organization: ISCA

I have several questions I'm hoping I can find out the answers to between the
two groups I've posted this to.  For question 3 the machine in question is an
HP 9000/710 running HP-UX 8.07, if that matters.

1)  For what functions does telnet rely on OOB data? (i.e. what would happen if
    OOB data was "lost" into /dev/null -- both sides of the connection could
    send it but wouldn't ever know it never made it to the other side)

2)  Same question for rlogin.

3)  Can a send(2) call attempting to write OOB data be blocked, or does the
    call always complete immediately since it uses a different logical channel
    and blocking tends to defeat the purpose of OOB data in the first place?

If anyone can answer one or more of these questions, please mail -- if others
indicate interest in the answers I'll summarize the responses I get.  Thanks!

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@icaen.uiowa.edu      |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Hi, I'm a .signature worm.  I've already copied myself into your .signature.
From: sap@crosfield.co.uk (stelios pavlides)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Use of ARP with non-IP protocols
Date: 14 Aug 92 17:35:36 GMT
Organization: Crosfield Electronics, Hemel Hempstead, United Kingdom.

In article <1992Aug7.133126.12636@webo.dg.com> dad@mozart.webo.dg.com writes:
>In article <15058@suns6.crosfield.co.uk>, sap@crosfield.co.uk (stelios pavlides) writes:
/|> 
/|> Assume there is a non-IP protocol, say XX, which nevertheless uses IP-style
/|> addresses and relies on ARP for address resolution (this conveniently
/|> exists for real in the name of XTP). What one should use in the ar$pro
/|> field of the ARP packet, the IP protocol type (a) or the XX protocol type
/|> (b)?
/|> 
/|> The case for (a) is that XX, although different to IP, should declare the
/|> IP address space that it uses. That is, ar$pro refers to the address space
/|> and not to the protocol itself.
/|> 
/|> The case for (b) is that one should have separate ARP tables on a per
/|> protocol basis, even if two protocols use the same address space.
/|> 
/
/From RFC 826 (An Ethernet Address Resolution Protocol --or--
/Converting Network Protocol Addresses to 48.bit Ethernet Address
/for Transmission on Ethernet Hardware):
/
/    16.bit: (ar$pro) Protocol address space.  For Ethernet
/                     hardware, this is from the set of type
/                     fields ether_typ$<protocol>. 
/
/Ethertype fields are 0x0800 for IP and 0x817D for XTP.

But that was precisely the nature of my question. Note that in your
citation above 'protocol ADDRESS SPACE' is first mentioned, not just
'protocol' (possibly an indication of the author's intention?). I
appreciate, of course, that the second sentence follows; but RFC 826 is
dated Nov 1982, at which point there was probably one-to-one correspondence
between 'protocol' and 'protocol address space'. This is no longer true
today.

-- 
Stelios Pavlides			Phone  :  +44 442 230000 ext 3468
Crosfield Electronics Ltd		Fax    :  +44 442 232301
Hemel Hempstead, Herts. HP2 7RH, UK	E-mail :  sap@crosfield.co.uk 
-----------------------------------------------------------------------------
From: bwill@athena.mit.edu (Brian F Williams)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP window size
Summary: how change you change the window size?
Date: 18 Aug 92 18:26:38 GMT
Organization: Massachusetts Institute of Technology


	It appears that the sun implementation of tcp uses a default
window size of 4K.  Is there a standard way of changing the window
size (a socket option?) or, if not, where can I change this value
on a sun Sparcstation?  Thanks.

--Brian
--
internet: bwill@athena.mit.edu
uucp    : mit-eddie!mit-athena!bwill
bitnet  : bwill@athena.mit.edu
Newsgroups: comp.protocols.tcp-ip