HDTenEightyP/NetNews huggingface dataset:
From: romkey@asylum.UUCP (John Romkey)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: UDP has to do an ARP after 1/2 hour of inactivity?
Date: 7 Oct 92 22:46:15 GMT

vittallo@ssd.comm.mot.com (John Vittallo) writes:
>I have two boards in a VME system that communicate using  
>UDP port #7000. The problem is that when there is a pause in 
>communication, about 1/2 hour,  the board that wants to send out 
>a message has to ARP the other board. During this ARP the message 
>never gets out. The software is expecting a response so it times out 
>and  sends another message. This message gets over without a problem.

>Is this a part of UDP, that it loses the ARP table for UDP destinations?
>Both boards, a VME 167 running UNIX and a VME 147 running PSOS are on a
>LARGE, BUSY, NETWORK. Users are using the 167 board for ftp, rlogin
>etc during my testing.

It should have nothing to do with UDP, per se. UDP should know nothing about
ARP or the media it's running over.

What's probably happening is one of these two things: 

ARP may be reusing the cache entry because no communication has
happened for half an hour. ARP implementations usually have caches
smaller than the total number of possible hosts they may be able
reasonably ARP; this is an okay assumption because on most networks a
system talks to very few other systems. An ARP implementation will
reuse a cache entry, usually the oldest one, if it runs out of empty
slots.

An ARP implementation should also expire old entries (as stated in host
requirements) because you don't want an ARP entry to get stale. This
is a protection against the system you're talking to changing its ethernet
address (as it might do if its ethernet board were replaced). If it
did and ARP didn't ever expire the address you wouldn't be able to talk
to the system again until you rebooted.

ARP should *not* throw away the packet that caused the ARP request, though,
so you should complain to your TCP/IP vendor that their ARP implementation
is behaving stupidly by doing this. Here host requirements overrides the
ARP RFC.
-- 
	- john romkey	  ELF Communications	 romkey@ELF.com
From: dougm@boulder.Central.Sun.COM (Doug McCallum)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Strange Output from 'netstat -a'.
Date: 8 Oct 92 17:34:37 GMT
Organization: SunSoft, Inc.
NNTP-Posting-Host: boulder.central.sun.com
In-reply-to: mikeg@Ingres.COM's message of 8 Oct 92 10:09:32 GMT

In article <1992Oct8.100932.18923@pony.Ingres.COM> mikeg@Ingres.COM (Mike Glendinning) writes:

   I did a 'netstat -a' command on a SVR4 box the other day, and it
   came up with this strange (and worrying) output.  Amidst the
   usual stuff, there were at least a dozen lines identical to the
   following:

      Proto Recv-Q Send-Q Local Address        Foreign Address    (state)

      tcp        0    536 *.*                  *.*                CLOSED

This is an artifact of STREAMS.  All it means is that there is an
STREAM that was opened to TCP that hasn't been bound or has been
unbound but not closed.  When the initial plumbing for TCP/IP is
setup, a STREAM is opened that doesn't get closed until the stack is
brought down at shutdown.  This is part of holding the stack together.
That is the origin of the first one.

You can get additional ones for a number of reasons.  For example, do
a "sleep 60 </dev/tcp &" and then do a "netstat -a" and you will see a
new one that will exists for as long as the stream is opened.

You can also get them when an application doesn't do a "close()" after
the connection has been closed.  You shouldn't get them with data in
the send Q.  That sounds like a bug.
From: ccurtis@acsu.buffalo.edu (Chris Curtis)
Newsgroups: comp.protocols.tcp-ip
Subject: Socket Communication Problem
Date: 14 Oct 92 19:13:45 GMT
Organization: State University of New York at Buffalo / CEDAR Research Group


  I'm attempting to implement socket communication between a server
process (which performs database queries) and a remote client process
which sends queries to the server.  I've encountered a problem with
respect to sending certain data structures via the write() command.
It appears that the size of the data structure is exceeding the size
of the buffer used in the associated read() command.  The symptom
is that occasionally the pipe will be broken by the server process. 

  Has anyone had similar problems?  If so, is there any way to increase
the buffer size used in socket communication?  I've found that I can
get the communication to work as long as I "break apart" the data
structure into smaller pieces, and insert sync points during the
send.  This slows down the communication process substantially, and
I was hoping to do better.

  Please e-mail me directly if you can shed any light on a solution
to my dilemma.


Thanks in advance,

Chris Curtis (ccurtis@cs.buffalo.edu)
From: pmod@pfbs.philips.se (Par-Mikael Odsater)
Newsgroups: comp.protocols.tcp-ip
Subject: KEEPALIVE ?????
Date: 10 Oct 92 20:44:02 GMT
Organization: Digital Equipment BCFI AB, Sweden

Hi Netters,

Does anybody know what KEEPALIVE is?

Please send me a e-mail if you know.

Best, P-M
--
 Par-Mikael (P-M) Odsater           | Digital Equipment BCFI AB
                                    | Box 904
 pmod@pfbs.philips.se               | S-175 29 Jarfalla, Sweden 
 ..!mcsun!seunet!dakotaS!pmod@pfbs  | Phone: +46 8 7594928, Fax: +46 8 7398676
From: dmiller@dragon.tricity.wsu.edu (David L. Miller)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Network Print under TCP/IP
Date: 16 Oct 92 18:01:40 GMT
Article-I.D.: serval.1992Oct16.180140.12131
Organization: Washington State University Tri-Cities

In article <2480016@hprnd.rose.hp.com>, k@hprnd.rose.hp.com (Steve Kao) writes:
|> If I understand you correctly, you want a network printer to accept jobs
|> from a unix box.  Netware 3.11 workstations will be connected to the
|> unix box, and all their printing to the network printer will be through
|> the unix box.
|> 
|> The IIISi has a network card that allows this as long as the unix box is
|> a SunOS Sparc station or an HP-UX box.  The card is the C2059T, and
|> costs $895.00 in the US.  You'll also need the appropriate media, and
|> the FAQ I'll append as the next note in this string should show how to
|> order the card.
|> 
The Sun version of the software also works on a DECstation.  The biggest
problem is copying the software...

|> 
|> - Steve Kao

-- 
*****************************************************************************
David L. Miller                       Internet: dmiller@beta.tricity.wsu.edu
Systems Programmer/Network Analyst      BITNET: MILLERD@WSUVM1
Washington State University Tri-Cities    UUCP: ...!yoda!dmiller
100 Sprout Road                          
Richland, WA 99352                       Phone: (509)375-9245
*****************************************************************************
Xref: sparky comp.protocols.tcp-ip:4699 comp.unix.ultrix:7495
From: alanlb@bethesda.cs.vt.edu (Alan L. Batongbacal)
Newsgroups: comp.protocols.tcp-ip,comp.unix.ultrix
Subject: WANTED: spray client for Ultrix
Date: 9 Oct 92 19:14:18 GMT
Followup-To: comp.protocols.tcp-ip

Hi there!  I recently installed an FDDI hookup between two DECstation
5000/240's running Ultrix 4.2a and would like to see just how far I
can push the link with regard to throughput.

I got hold of tcpspray from some archive and need a responding client
on the other side (which Ultrix apparently does not provide).  Is there
source available for such a client?  If not, what do you suggest I use
as a means of benchmarking the link?

Thank you!

alan l. batongbacal
From: art@acc.com (Art Berggreen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP over Ethernet: LSAP=6 vs. SNAP
Date: 9 Oct 92 16:46:39 GMT
Organization: ACC, Advanced Computer Communications

In article <1b3cfoINNing@skat.usc.edu> tli@skat.usc.edu (Tony Li) writes:
>    IP over LANs depends on the use of ARP.  Given the limited number of
>    available 802.2 LSAPs, IEEE would not assign one for ARP, but was
>    convinced to allocate one for the SNAP mechanism.  
>
>So people frequently use HP probe as an ARP substitute when running 802.3.

Is Probe really used anywhere but on networks running older versions of HP
TCP/IP?

>    You could still run DIX and 802.3/802.2 versions of IP on the same wire.
>    SNAP is just the preferred encoding.
>
>... by the standards bodies.  Almost everyone is using (or is
>migrating towards) DIX. 

Guess I wasn't clear enough.  I was just pointing out that either
802.3/802.2/IP or 802.3/802.2/SNAP/IP would co-exist with DIX Ethernet
(all three for that matter), but that SNAP was preferred to raw 802.2.
I agree that for IP (and most non ISO protocols), DIX Ethernet is preferred.

Art
Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans.misc,comp.dcom.lans.ethernet
From: westes@sti.com (Will Estes)
Subject: Good References For Deciphering Output Of An Analyzer?
Organization: Mail Group
Date: Fri, 16 Oct 1992 02:58:20 GMT

I have a simple public-domain network analyzer that I set up to help me
determine the source of a network problem.   Unfortunately, this
particular analyzer gives me some pretty crude output.  It basically
spits out the packet type number and then the header of the packet.
There are not any summary statistics.

Does anyone know of a good reference that will give me numbers for the 
different packet types, as well as a breakdown of the packet structure?  
I don't need a PhD thesis in terms of detail...I'm looking for more like 
Cliff Notes on packet analysis (yes, that was a serious remark :).  The
ideal book would spell out the five or six most common kinds of problems
and then spell out what kind of signature that problem leaves on the
network in terms of packets being passed back and forth.  Does 
anyone know of any good documents/books to get?  Anything by ftp?
Our net is running Novell and TCP traffic over ethernet, so those are the 
only cases I need to cover.

Someone had suggested that my problem might be caused by an SQE problem
and some other station on my segment erroneously sending out collision-detection
packets (if that is nonsense, forgive me).  What sort of signature
would this kind of problem have? 

-- 
Will Estes		Internet: westes@netcom.com
Newsgroups: comp.protocols.tcp-ip
From: wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
Subject: Re: Telnet server that runs on a PC?
Organization: AT&T Bell Labs Random Organization Name Generator
Date: Wed, 14 Oct 1992 05:20:27 GMT
	<1992Oct08.143354.24594@sernews.raleigh.ibm.com>

   > I am looking for a telnet server that will run on a PC and that is 
   > capable of running Dos applications simultaneously.  If you have 
   TCP/IP for OS/2 has this function

DESQview/X can also do this, letting you run DOS apps remotely from an
X Window, if you have it set up right.
--
				Pray for peace;      Bill
#Bill Stewart 908-949-0705 wcs@anchor.ho.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Trickle-Down Economics: Giving money to government bureaucrats 
#	and hoping some will trickle down to the people who need help.
From: k@hprnd.rose.hp.com (Steve Kao)
Date: Tue, 13 Oct 1992 15:45:12 GMT
Subject: Re: Network Print under TCP/IP
Organization: HP Roseville Networks Division
Newsgroups: comp.protocols.tcp-ip

If I understand you correctly, you want a network printer to accept jobs
from a unix box.  Netware 3.11 workstations will be connected to the
unix box, and all their printing to the network printer will be through
the unix box.

The IIISi has a network card that allows this as long as the unix box is
a SunOS Sparc station or an HP-UX box.  The card is the C2059T, and
costs $895.00 in the US.  You'll also need the appropriate media, and
the FAQ I'll append as the next note in this string should show how to
order the card.

Note that the IIISi also has a Novell Netware card.  If the unix box
will be doing very little printing and the Netware workstations a lot,
you may want to get this card instead.  It costs $695 in the US.  I have
no FAQ for it.

- Steve Kao
Newsgroups: comp.protocols.tcp-ip
From: donp@novell.com (don provan)
Subject: Re: what does completion of write() really mean?
Keywords: TCP Nagle
Organization: Novell, Inc., San Jose, California
Date: Wed, 14 Oct 1992 00:43:12 GMT

In article <qnblp1k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Never mind that combining the write()'s is the obvious thing to do.
>The X guys say they have good reasons.

Tell the X guys that their reasons, whatever they are, aren't good
enough to justify doubling the number of packets sent and, hence,
doubling the impact their application has on the network
infrastructure.  Blaming the poor performance of this transmission
"technique" on TCP is something like using low octane gas in a race
car, and then blaming the poor performance on the engine.

						don provan
						donp@novell.com
From: dmiller@dragon.tricity.wsu.edu (David L. Miller)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Network Print under TCP/IP
Date: 17 Oct 92 02:18:17 GMT
Article-I.D.: serval.1992Oct17.021817.18271
Organization: Washington State University Tri-Cities

The HP JetDirect card uses port 9100.

In article <1992Oct17.014428.10452@oar.net>, tga@oar.net (Germann Associates) writes:
|> 
|> For those of us who forgot to hit the s key in rn, what tcp port does the 
|> HP TCP card use?
|> 
|> Eric
|> 
|> eric@tga.com
|> 
|> -- 
|> ============================================================================
|> 
|> Eric Germann                               Quote for the time being:
|> The Germann Associates                     "Lead, follow, or get out of the 

-- 
*****************************************************************************
David L. Miller                       Internet: dmiller@beta.tricity.wsu.edu
Systems Programmer/Network Analyst      BITNET: MILLERD@WSUVM1
Washington State University Tri-Cities    UUCP: ...!yoda!dmiller
100 Sprout Road                          
Richland, WA 99352                       Phone: (509)375-9245
*****************************************************************************
Newsgroups: comp.protocols.tcp-ip
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: UDP has to do an ARP after 1/2 hour of inactivity?
Date: Thu, 8 Oct 1992 09:45:11 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <1992Oct7.202638.19578@lmpsbbs.comm.mot.com> vittallo@ssd.comm.mot.com (John Vittallo) writes:

>I have two boards in a VME system that communicate using  
>UDP port #7000. The problem is that when there is a pause in 
>communication, about 1/2 hour,  the board that wants to send out 
>a message has to ARP the other board. During this ARP the message 
>never gets out. The software is expecting a response so it times out 
>and  sends another message. This message gets over without a problem.

>Is this a part of UDP, that it loses the ARP table for UDP destinations?
>Both boards, a VME 167 running UNIX and a VME 147 running PSOS are on a
>LARGE, BUSY, NETWORK. Users are using the 167 board for ftp, rlogin
>etc during my testing.

I found a thing (bug?) in SVR4, where a large (larger than the MTU)
packet was split up in two (to cater for the MTU) and the two parts sent
one after the other. The first one was queued due to a missing ARP entry
(this was the first packet being sent to the destination or the ARP
entry had aged out). When the second part was to be sent immediately
after the first one was queued (the ARP request still on the way), it
was dropped, because the code allowed only for one packet to be queued.

You can try this by calling "ping" with a packet size set to the
network's MTU (the additional header(s) will push it past the limit) and
fiddling around with ARP entries (use "arp" to selectively remove the
entries.) You'll lose the first "ping"-packet!
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
From: shlam@eng.ie.cuhk.hk (Alan S H Lam)
Subject: SLIP for ULTRIX and MSDOS
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Tue, 6 Oct 1992 10:19:11 GMT


I know it had been asked before but I missed them.
Sorry for asking again. 

Could anyone tell me where I can get the 
SLIP driver for ULTRIX 4.2 on DEC machine and
SLIP driver for MSDOS on PC?

If anyone know it, please send me a e-mail.
I will very appreciate it. Thanks.


--
Alan S. H. Lam
Department of Information Engineering, CUHK, Hong Kong
E-mail: shlam@eng.ie.cuhk.hk 
Tel: (852) 609 7975 Fax: (852) 603 5032
From: barr@pop.psu.edu (David Barr)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ping Reports: 31% Packet Loss...Possible Causes?
Date: 14 Oct 92 21:34:07 GMT
Article-I.D.: atlantis.m291Hg915a
Organization: Penn State Population Research Institute

In article <1992Oct14.075613.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
>In article <-071H6tx4a@atlantis.psu.edu>, barr@pop.psu.edu (David Barr) writes:
>Not again! It seems that SQE is about the top area of total confusion in LANs.
>This advice is simply WRONG! If in doubt, get a book on the subject. But PLEASE
>don't post this sort of advice!

How about "Keeping the Link" by Martin Nemzow?

>SQE is a signal passed between the transceiver and the host. It does not send
>out any signal on the backbone media.

p 55. "When the network is not busy, and idle signal is transmitted by all
source/destination nodes, which is the 0.7-volt carrier sense.  This base
voltage is sometimes called the 'heartbeat.'"

Hm.   This sure sounds like a signal to me.

>802.3 mandates SQE for all terminal
>devices. That means anything EXCEPT a repeater.

Yep.  It is for exactly this reason that I've had to turn off SQE
on my one network.  It seems the repeater (a CISCO AGS) that I get doesn't
handle SQE, and if I have it enabled on my machines, the network quickly
grinds to a halt as the repeater dumps collision notices onto the wire.

>SQE exists because there is no
>other way for a system to know that its collision detection circuitry has
>failed. And the failure of this circuitry can result in major network failure.

Fine.  There are also cases when leaving it on results in major network
failure.  Solution?  If it hurts, don't do it.

>There is a good sized article on SQE in the biglan FAQ which was recently
>posted to comp.dcom.lans.ethernet. (OK. I'm a bit biased because I wrote it.)
>
>There are any number of things which might produce the symptoms reported.

Of course.  We all know that.  I just suggested one plausable thing to
check.  If it turns out not to be an incompatable ethernet device, then
you look for other problems.  No harm in checking.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.protocols.tcp-ip
Subject: Host Requirements testing ?
Date: 9 Oct 92 18:49:03 GMT
Distribution: na
Organization: Naval Research Laboratory, DC


  Are there any freely distributable programs that test a host's
conformance to the requirements of the Host Requirements RFCs (RFC
1122 and RFC 1123) ?

  Please email and I'll summarise back to the list.

Ran
atkinson@itd.nrl.navy.mil
Newsgroups: comp.protocols.tcp-ip
From: wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
Subject: Re: Password capture on anonymous FTP?
Organization: AT&T Bell Labs Random Organization Name Generator
Date: Wed, 14 Oct 1992 04:33:26 GMT

How to find who's ftping your stuff?
In article <717817072snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
   Technological fix: insist on an email address as a password.
   You might do something like insist on a valid and/or valid-looking
   address.  The wustl FTP server checks for valid-looking addresses.

But *please* don't.  uunet does this.  The ftp-across-firewall code we
use limits passwords to 8 characters (unless the new version fixes it),
so I can't put my real email address there, just a bogus string that
has the right syntax like me@x.com .  So my .netrc has to have a
special case for talking to them that uses that instead of wcs@att,
since I'm not going to type in anonymous by hand :-)

If you want a technological fix, keep track of their IP address.

   Sociological fix: Ask them for a valid email address.
Much nicer!
--
				Pray for peace;      Bill
#Bill Stewart 908-949-0705 wcs@anchor.ho.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Trickle-Down Economics: Giving money to government bureaucrats 
#	and hoping some will trickle down to the people who need help.
Newsgroups: comp.protocols.tcp-ip,comp.sys.novell
From: J045820@LMSC5.IS.LMSC.LOCKHEED.COM
Subject: Hardware address translation
Organization: Lockheed Missiles & Space Company, Inc.
Date: Fri, 16 Oct 92 13:52:24 GMT

Hello , I have a question concerning or resolving may be a better way to
say it of, IP addresses to physical card addresses. I understand that
the physical address should be found during installation, but inevitably
one will be missed, so that brings me to my problem. Using a Sunworkstation
as a management tool, and the related network status commands such as netstat
ping and others is it possible to glean the physical addresses to coincide
with IP addresses. I understand this can be done with a protocol analyser
but I am trying to develope this capability from a central system (Sun).
If anyone has any suggestions I would appreciate the information.
                                      Thanks Bill Smith ,(LMSC)
From: cs161fgp@sdcc10.ucsd.edu (Adam Tilghman)
Newsgroups: comp.protocols.tcp-ip
Subject: Can I run SLIP over a telnet session?
Date: 13 Oct 92 21:45:09 GMT
Organization: University of California, San Diego


  The subject pretty much says it all - can I telnet into a machine
running a SL/IP server?  What if I use an 8-bit-clean rlogin
connection?

    Any info would be appreciated. 

    -- adam

Adam G. Tilghman - atilghma@ucsd.edu - Voice: (619)622-1944 <10pmPST
From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Why is there no FAQ for this newsgroup?
Date: 16 Oct 92 23:34:11 GMT
Reply-To: lstowell@pyrnova.pyramid.com (Lon Stowell)
Organization: Pyramid Technology Corp., Mountain View, CA

In article <139152@lll-winken.LLNL.GOV> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
>Has anyone here ever considered putting together an FAQ for this newsgroup?
  Well, the ANSWERS are called RFC's...... >:-)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.misc,comp.os.msdos.misc,comp.os.msdos.programmer