HDTenEightyP/NetNews huggingface dataset:
From: ms@Germany.EU.net (Marc Sheldon)
Newsgroups: comp.protocols.tcp-ip,comp.dcom.isdn
Subject: Re: TCP/IP over ISDN
Date: 4 Sep 92 21:27:45 GMT
Organization: EUnet Backbone, Dortmund, Germany
NNTP-Posting-Host: walhalla.germany.eu.net

urlichs@smurf.sub.org (Matthias Urlichs) writes:
> Unfortunately, the original request came from Germany.
> We don't have Q.931 (yet). We also don't have user-user data; maximum
> user information transmittable during call setup is 10 bits in forward
> direction (device address (1 decimal digit) and 2nd byte of service type)
> and 6 bits back (the cause value). So polling is possible, though I'd rather
> use it to ask if there's anything in the UUCP queue for the calling system.

Sorry to correct you there, but there are not even that many Bits
to transmit. The second byte of the service type (i believe it is
called "Additional information") ist not available because the applicable
German Standard (1TR6) disagrees with itself on the point of transmission
of AI if you use the 64 kBit clear channel data service. According
to the 1TR6 the switch can either transmit AI transparently (so quoted
somewhere at the beginning of the standard) or it can set it to zero
(so quoted somewhere at the end of the SAME standard). We had several
problems with this as we used AI as a protocol identifier just to find
that some german PTT switches (namely those from Alcatel) set AI to
zero and some (namely those from Siemens) pass AI through. After we
informed the DBP Telekom about this inconsistency we were told that
the software on the Siemens switches would be changed to set AI to
zero, thereby making our use of AI impossible. So much for passing
User-to-User-Information.

Cheers,
	Marc
--
Marc R. Sheldon                             e-mail : ms@Germany.EU.net
EUnet Germany
University of Dortmund, CS-Department
P.O.Box 500500                              voice  : +49 231 7552444
From: mgic@mixcom.mixcom.com (mgic)
Newsgroups: comp.protocols.tcp-ip
Subject: server that won't die (normally)
Date: 1 Sep 92 20:58:51 GMT
Article-I.D.: mixcom.1992Sep01.205851.29040
Distribution: usa
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.


System: RS/6000 AIX 3.2.1

I've written a server that is started by inetd, reading
and writing stdin and stdout.

The server uses select() to determine when data is
ready to be read. If an (socket) error is detected, 
the server quits.

The problem is that the server never dies if the client
quits abnormally. When the client quits normally, it sends
the server an "end of session" message, and the server quits normally.

Why isn't the server being informed that the client no longer exists
so that select() will report an error? Or, what method should
be used to determine if the stream no longer exists?

Thank you.

Dean
--
From: sklower@diva.Berkeley.EDU (Keith Sklower)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: What are the Pros/Cons of Multi-protocol routing?
Date: 26 Aug 92 08:17:33 GMT
Distribution: usa
Organization: U. C. Berkeley EECS/TCS

In article <17bfvnINNrgt@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
}In article <l9i4eiINNocr@noc.near.net> kwe@noc.near.net (Kent England) writes:
}>I think it is stretching the definition of an internet protocol to
}>include X.25.
>Is it really? ...  There are gateways between Tymnet, Telenet, Datapac, and
>various regional telephone company networks.

The last time I checked, I was severely thwarted in attempts to establish
an X.25 connection between me on accunet and apple computer on telenet,
even tough Apple's network manager and I both wanted to do some
interoperability testing.

After much pulling of strings and threating to cut off service (and
nearly being called a liar to my face by the ATT technical
representative to OSINET, I was told that I might be granted permission
to do that if I were to write a technical proposal to OSINET detailing
exactly what kind of testing I had in mind, and why UC Berkeley
couldn't afford to shell $7K to join OSINET, and blah, blah, blah.
I wound up doing some testing against the CDNnet people in toronto.

I would say that X.75 interconnectivity is FAR from comlete.
From: erik@yarra.pyramid.com.au (Erik Lecis)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Text/Book recommendations for TCP-IP
Summary: Book recommendations for TCP/IP
Date: 28 Aug 92 23:45:50 GMT
Organization: Pyramid Technology Corp PL, Melb., Australia

In article <BtLJH0.Cw3@world.std.com>, aep@world.std.com (Andrew E Page) writes:
> 
>     Does anyone have any recommendations for a good book on TCP-IP
> protocol(s), implentations, use/abuse, etc.  I'm looking at debugging
> som hardware/firmware that may not be implementing the protocol properly.  
> 
A really useful book I'm using is:

"Troubleshooting TCP/IP - Analyzing the Protocols of the Internet" by
Mark A. Miller, 1992, published by M&T Books. List price is US$44.95.

The author "presents over 25 case studies, take from live internetworks,
that demonstrate TCP/IP and the related protocols they use, typical problems
that may occur, plus solutions".

The case studies are presented in the form of Sniffer packet traces, which
are then methodically analysed.

I can't recommend it highly enough, especially if you have a Sniffer!

- Erik.
Newsgroups: comp.protocols.tcp-ip
From: kannan@oar.net (Kannan Varadhan)
Subject: Re: Extending IP-numbers
Organization: Ohio Supercomputer Center & OARNet, Columbus, OH
Date: Wed, 26 Aug 1992 20:07:05 GMT

Thus spake avalon@coombs.anu.edu.au (Darren Reed)
>berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>>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?)
>
>ftp to munnari.oz.au (anonymous) and take a peek in /big-internet.

Associated mailing lists are big-internet-request@munnari.oz.au,
tuba-request@lanl.gov, ip-encaps-request@lanl.gov and
pip-request@thumper.bellcore.com to join.


Kannan
-- 
Kannan Varadhan,		1224, Kinnear Road,	+1 614 292 4137
Internet Engineer (OARnet)	Columbus, OH 43212	+1 614 292 7168 (FAX)
Newsgroups: comp.protocols.tcp-ip
From: mack23@avalon.eecs.nwu.edu (Chris Walsh)
Subject: Comer and Stevens source available, ordering info
Originator: mack23@avalon.eecs.nwu.edu
Organization: EECS Department, Northwestern University
Date: Mon, 31 Aug 1992 14:22:55 GMT

Several people have contacted me regarding the availabilty of the source 
listings from Comer and Stevens, vol. II.  

The source is available, for a (IMHO) reasonable price.  D. Stevens contacted
me with ordering info, but asked that I not post it to the net because this
would be commercial use.  In deference to his wishes, I have reproduced it 
below, with the prices x'ed out.  He will send an unexpurgated version to
anyone who asks.  Stevens' e-mail address is: dls@mentor.cc.purdue.edu 

Herewith, the info from Stevens:

----
	You can order a tape by sending $xx.95 + sales tax for your area (they
pay shipping for prepaid orders) to:

			Book Distribution Center
			Prentice Hall
			Route 59 at Brook Hill Drive
			West Nyack, NY 10995

	For 1/4" Sun cartridge tape, the order number is 47322-3. For 1600 BPI
9-track tape, it is 47233-2.

	You can also order the latest release directly, including some bug
fixes and minor (so far) enhancements that have not made it to the Prentice
Hall distribution yet. To do that, send a check payable to "David L Stevens"
for $xxx to:

			David L Stevens
			c/o Xinu Librarian
			Computer Science Bldg Room 156
			West Lafayette, IN 47907

	Thanks for your interest in the book!

							+-DLS


Any further requests *I* get will be forwarded to Stevens.


--
Chris Walsh                               Pithy Quotation Wanted
TechNet Network Administrator             ----------------------
2145 Sheridan Rd.                         Send candidates to: 
1-5366                                    mack23@avalon.eecs.nwu.edu

Newsgroups: comp.protocols.tcp-ip
From: tengi@princeton.edu (Christopher Tengi)
Subject: looking for tn3270d
Originator: news@nimaster
Keywords: telnet, tn3270
Organization: Princeton University - CIT
Date: Thu, 3 Sep 1992 21:20:29 GMT

I am looking for a tn3270 daemon so that folks around here can telnet
from our VM system to a unix system, and be able to do things in a
full screen mode.  Strangely enough, one of the things that might be
wanted is to tn3270 back out of the unix system to another VM system.
I know that it sounds ugly, but, unfortunately, there really is a need
for this behaviour.

So has anybody out there heard of/written such a beast?  I checked
archie for .*3270.*, but only found things that looked like the user
side, not the server side.

					/Chris

==========----------==========---------+---------==========----------==========

	UUCP:	  ...princeton!tengi		VOICEnet: 609-258-6799
	INTERNET: tengi@princeton.edu		FAX:      609-258-3943
	BITNET:	  TENGI@PUCC
Newsgroups: comp.protocols.tcp-ip
From: jblaine@fsu1.cc.fsu.edu (Jeff Blaine)
Subject: SLIP FAQ ?
Followup-To:  poster
News-Software: VAX/VMS VNEWS 1.3-4   
Keywords:  SLIP
Reply-To: jblaine@fsu1.cc.fsu.edu
Organization: Florida State University
Distribution:  world
Date: 25 AUG 92 21:35:30    

Does a SLIP FAQ exist?  If so can anyone please shove me in the direction 
of one, or any SLIP general docs for that matter?  Any help would greatly 
be appreciated.

jblaine@fsu1.cc.fsu.edu
-_-____________________________________________________________________-_-

Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.os2.misc,comp.os.os2.networking
From: oleg@watson.ibm.com (Oleg Vishnepolsky)
Subject: Re: Need help with getting IBM's TCP/IP running under OS/2
Date: Fri, 28 Aug 1992 15:58:04 GMT
News-Software: IBM OS/2 PM RN (NR/2) v0.1 by O. Vishnepolsky and R. Rogers
Reply-To: oleg@watson.ibm.com (Oleg Vishnepolsky)
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

In  <1992Aug28.155005.25410@watson.ibm.com>  oleg@watson.ibm.com (Oleg Vishnepolsky) writes:
> In  <Btp7wu.2Bv@fmsrl7.srl.ford.com>  probert@fires1.uucp (Neal W. Probert) writes:
> > I just installed the 3COM 3c505 driver for OS/2 2.0 for use with IBM`s
> > TCP/IP package.  Here's what I get from STARTUP.CMD:
> >
> > CALL C:\TCPIP\BIN\TCPSTART.CMD
> > CONFIGURING TCP/IP
> > add net default: router 128.5.192.3: (null): Network is unreachable
>
> What happened to your ifconfig statement ? Without setting an IP address
> for your network interface, any network would be unreachable.

Please also make sure that if you do have ifconfig in your startup.cmd,
that ip address it sets is on the same net as your default router.

Oleg Vishnepolsky
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Broadcasting and Subnets
Date: 3 Sep 1992 08:18:00 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <2490@cronos.metaphor.com> pstevens@Metaphor.COM (Paul Stevens) writes:
>When I want to send a broadcast packet to all stations on a net or
>subnet I set the IP address so that it contains the network/subnet
>numbers but set the host portion to all 1's.  This is, of course,
>net/subnet OR'ed with the inverse of the subnet mask.  Presumably 
>this style of addressing even works for a net/subnet that might be
>several hops away (i.e. the routers along the route will use the 
>net/subnet fields of the IP address to route the packet to the proper
>net/subnet).  My basic question concerns how to get a the correct
>subnet mask.

There's no common method for this.  In general, hosts are only expected to
know the subnet mask for their local networks.  Hosts are only supposed to
use subnet masks to determine whether a destination can be reached directly
or must go via a router.  All non-local addresses are equivalent to hosts.

Recent routing protocols transmit subnet masks along with routes, but these
are intended only for use by routers, not individual hosts.

Sending broadcasts to remote networks is frowned upon, so there's no
special support to make it easy.  If you want to do it, you're on your own
for a mechanism to learn the appropriate broadcast address for that subnet.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: epc1@quads.uchicago.edu (Merlin)
Newsgroups: comp.protocols.tcp-ip
Subject: 21 step guide to setting up DNS
Date: 3 Sep 92 14:39:04 GMT
Reply-To: epc1@midway.uchicago.edu
Organization: University of Chicago Computing Organizations

Thanks


-- 
En Pum Cho					
University of Chicago Class of 1994
math & economics major
epc1@midway.uchicago.edu
Newsgroups: comp.protocols.tcp-ip
From: jjensen@convex.com (James Jensen)
Subject: Re: Dynamically setting the TCP window is hard ?
Date: Thu, 3 Sep 1992 00:05:33 GMT
Organization: USENET news support, CONVEX Computer Corp, Richardson, Tx. USA
Followup-To: comp.protocols.tcp-ip
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

oak@odda.er.sintef.no (Olav Kvittem) writes:
- I want to set the TCP window selectively for high performance  sessions on a high
- bandwith*delay network.  
- 
- I have tried to set the max windowsize for TCP on BSD-type systems with the
- setsockopt( SO_RCVBUF ). That means setting the TCP internal receive buffer.

- well with SunOs 4.1.1/2, Cray/Unicos v6.013 and HP/UX systems, but  DECstation
- 5000 Ultrix v4.2 does not announce a higher window than 32K on the initial SYN
- 
- What is the actual mechanism for TCP to determine max inital receive window
- size and for me to influence it ?
- 
- Common to all systems above except Unicos is that they does not accept a higher 
- buffersize than about 50K - why is that ?
- 
- I guess that you can generate a kernel with fixed TCP buffersize larger than
- 50K. Then all TCP session for that system would have let say 64K window. Would that be more harmful to slow speed, normal delay , 64Kbps, networks than a 4K window ?
- 
It sounds like you are doing the right thing.  Unless you have the
sources to the kernel there probably isn't a lot more you can do about it.
The larger buffer may still be buying you some performance even though
it isn't advertised.  It should allow the window to stay all the way
open even if the application's read is delayed.

The problem with BSD based tcp is that it had hidden assumptions, and
some not so hidden, that they were going over ethernet or some other network 
that didn't need a big window.  This has slowly changed, but modifying tcp 
is pretty scary.  tcp_input() has over 1000 lines in one routine full of 
gotos and subroutines with magic side effects.

I suspect the DECstation still has the window stuff declared as signed
16 bit numbers.  I have no idea where the 50k limit is coming from.

One thing you might want to watch out for is that some implementations
of tcp don't work very well if the socket buffers aren't the same size
on both sides of the connection.

Jim Jensen - jjensen@convex.com
Newsgroups: comp.protocols.tcp-ip
From: steveh@devildog.att.com (Steve Hendershott)
Subject: Looking for SNMP Trap Sending Program
Organization: AT&T IMS - Piscataway, NJ (USA)
Distribution: na
Date: Thu, 27 Aug 1992 15:14:59 GMT

Does anyone have or know where I can get the source for an SNMP trap sending
program. In particular I'd like to be able to modify the variable bindings
and have it work on a UNIX machine. I really need source code to make this
work. I would appreciate any help directly or where I can FTP this
type of program.

Thanks.
-- 
Stephen W. Hendershott
steveh@devildog.att.com
From: donp@novell.com (don provan)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP: RFC interpretation
Keywords: FTP, RFC959
Date: 28 Aug 92 00:26:47 GMT
Organization: Novell, Inc., San Jose, California

In article <1992Aug20.030954.4831@cssc-woll.tansu.com.au> brian@cssc-woll.tansu.com.au (byrnes brian) writes:
>I am currently having a disagreement with IBM regarding their
>interpretation of RFC959.  I am using their MVS FTP server 
>(part of their TCP/IP for MVS package), and I think their 
>server does not adhere to the RFC.  IBM  disagrees.

This point of RFC959 has been clarified by RFC1123, "Requirements for
Internet Hosts -- Application and Support".  In general, it says that
IBM shouldn't be making up numbers, but your FTP client also shouldn't
assume specific response codes instead of basing its reaction solely
on the highest digit of the response.  Specifically, from 4.1.2.11 on
page 33 of RFC1123:

Begin quote:

            A Server-FTP SHOULD use the reply codes defined in RFC-959
            whenever they apply.  However, a server-FTP MAY use a
            different reply code when needed, as long as the general
            rules of Section 4.2 are followed. When the implementor has
            a choice between a 4xx and 5xx reply code, a Server-FTP
            SHOULD send a 4xx (temporary failure) code when there is any
            reasonable possibility that a failed FTP will succeed a few
            hours later.

            A User-FTP SHOULD generally use only the highest-order digit
            of a 3-digit reply code for making a procedural decision, to
            prevent difficulties when a Server-FTP uses non-standard
            reply codes.

End quote.

						don provan
						donp@novell.com
Xref: sparky comp.protocols.tcp-ip:4252 comp.protocols.tcp-ip.ibmpc:4982
From: starrenb@ptt-iat (John Starrenburg)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: HELP with hanging NetCI in UB's TCP BNS/NDIS with UCX 2.0
Keywords: UCX, UB, TCP, NDIS
Date: 1 Sep 92 11:28:19 GMT
Followup-To: poster
Organization: PTT Telecom B.V. I&AT NWDS-DS-OOTA , Groningen The Netherlands

Whenever I do a DISCONNECT from The Connection Assistant (NetCI), the session
manager that is integrated with Ungermann-Bass' TCP/IP stack for the PC,
TCP BNS/NDIS, and I am connected to a VAX with UCX 2.0, NetCI hangs. The
problem is probably because UCX 2.0 sends a logoff message after the TCP/IP 
FINish, which is conform the RFC. When tested against MultiNet or a UNIX box,
everything works fine. These stacks don't send any further data after the FIN 
from the PC. The PC itself works fine after the hanging NetCI, but when I
try to start my Windows Comms package DynaComm (or Reflection), no NetCI
prompt appears. NetCI uses software INT 6Bh for communication with these 
comms pacakges. The reason why I think it is NetCI that is failing is because
the DOS versions of FTP and Telnet work fine. I assume these progs interface
with the TCP/IP stack directly, instead of the comms packages which use 
NetCI as session manager.
Hope this is enough information for those who might know the answer. Any 
help and/or clues are GREATLY APPRECIATED, because we are approaching a
deadline.
Thanx in advance.
____
John
-- 
---------------------------------------
John Starrenburg    I&AT    PTT Telecom
Internet: starrenb%ptt-iat@nluug.nl
Xref: sparky comp.protocols.tcp-ip:4298 comp.dcom.isdn:511
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.protocols.tcp-ip,comp.dcom.isdn
Subject: Re: TCP/IP over ISDN
Date: 4 Sep 1992 11:03:00 +0200
Organization: University of Karlsruhe, FRG

In comp.protocols.tcp-ip, article <1992Aug31.183707.18401@gandalf.ca>,
  djarrett@gandalf.ca (Dave Jarrett) writes:
> In article <1992Aug28.114002.25416@stc.nato.int> koelman@stc.nato.int writes:
> >> 
> >>  - When the idle timer expires, the ISDN server issue a B-channel 
> >>    connect request to the client ISDN station. The user-user data field
> >>    in the connect request contains a "poll" command. 
> >> 
... which would require both sides of the ISDN connection to keep state about
the TCP connections crossing the ISDN link and to send bogus TCP packets to
check if the system on the other side is still there. IMHO, this is not a
reasonable requirement.

> >> This approach has two advantages over polling using SYNs:
> >>  2. This approach is LAN protocol independant.
> >> 
Since TCP/IP is LAN protocol independent by definition, anything you do would
have to be.
> >
> >This would imply that you get bandwidth for free through the
> >user-to-user data  (unless that is charged separately).
> >I don't think PTTs are that stupid.
User-user data has some valid applications, such as the transmission of
login information, or to check if your voice mail system has any new messages
without actually calling in. ;-)

> >If they are then let's send all our IP traffic this way...
> >(the MTU may be limited though :-))

Q.931 does limit the number and length of such data packets.
The ISDN switch might also raise some alert if you're continuously trying
to open connections, which are all mysteriously rejected; the main reason
is that such processing causes an excessive load on the switch. 
> 
> It is true that user-user data is an optional facility in Q.931.

Unfortunately, the original request came from Germany.
We don't have Q.931 (yet). We also don't have user-user data; maximum
user information transmittable during call setup is 10 bits in forward
direction (device address (1 decimal digit) and 2nd byte of service type)
and 6 bits back (the cause value). So polling is possible, though I'd rather
use it to ask if there's anything in the UUCP queue for the calling system.

-- 
"Life would be much simpler and things would get done much faster if it
weren't for other people"
		-- Blore
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/
From: birchall@pilot.njin.net (Shag)
Newsgroups: comp.protocols.tcp-ip
Subject: SL/IP clues sought, cheap.
Summary: No idea where to begin...
Keywords: SLIP PC Cisco Sparc Ka9q?
Date: 28 Aug 92 20:07:52 GMT
Organization: Screaming in Digital, the Queensryche Net Digest


	Greetings.

	Being a lazy netrunner, instead of poking around a couple thousand 
FTP directories looking at every SLIP implementation known to mankind [and
probably a few other species], I'm going to ask some questions.

	First, the facts.

	My end:
	80286-16 PC, 1mb RAM, 80mb HD [65mb free], PPI 14.4kbps modem.

	The dialin:
	Cisco box with Multitech 9.6kbps modem, I have a TACACS login.

	This account:
	Sparcstation-II, connected to the Cisco via T-1.

	I've seen things stated on some local newsgroups that lead me to
believe I can, having a TACACS login on the dialin, run SLIP off it, or
off the Sparc, or off something.

	I've poked around a couple FTP sites, and downloaded the most 
promising looking Zipfile... which turned out to be a couple hundred K of
documentation.  Ack.  [Noack]

	I've been told ka9q can handle SLIP nicely, which encourages me,
although the documentation doesn't really say a whole lot about handling
it over a dialup connection, instead of packet radio, which I don't have.

	If someone out there could suggest specific files to get [and 
perhaps even specific FTP sites from whence to get them], I'd be a rather
happy camper, and probably stop asking silly questions for a couple days
while I tried to get it set up right.

	Of course, if you just want to tell me I'm silly, that's okay too.
But anyway.  Any answer is better than no answer.

	-Shag
-- 

     Freedom belongs to only those without video screens for eyes and mouth.
		- Queensryche
Newsgroups: comp.protocols.tcp-ip,comp.protocol.tcp-ip.ibmpc