HDTenEightyP/NetNews huggingface dataset:
From: barnett@grymoire.crd.ge.com (Bruce Barnett)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
Date: 8 Jan 93 19:22:35 GMT
Reply-To: barnett@crdgw1.ge.com
Organization: GE Corp. R & D, Schenectady, NY

In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
>      Transmitting using what protocol?   FTP, NFS copy or what?

It's TCP based. Similar to FTP.

>>Packets are missed by the archive system, so the Sun has to retransmit
>>the missed packets. I have noticed large delays (0.5 - 1.5 seconds)

>   Those are pretty typical numbers for TCP layer time-outs...


Thomas Narten mentioned that the granularity of the retransmit timer
is a multiple of 0.5 seconds. Also for every ACK of one segment sent,
you have to restart the timer for the next segment.

I wonder if a finer granularity on the retransmit value would help if
the peer is on the same network? I guess this is tough because some
peers may be slow and some may be fast. It could keep track of the
time for an ACK and try to pick a timeout near that time, I guess.....


>     If this is FTP, you'd probably be better off getting rid of the
>     fatal collisions on the net.....unless you can set the time-outs
>     to a very small number (very dangerous, but....)

It's not collisions, because I saw the packets being sent.  It seems
the receiver _missed_ seeing the packets on Ethernet. People have told
me the best solution is to upgrade the receiver. This could be a
hardware upgrade (faster CPU, more memory, more ethernet ports,
smarter ethernet ports, etc.) and possibly some software tuning. Does
anyone have advice on the relative advantage of each option? How much
would more memory help? A faster CPU? A second CPU? A second Ethernet
card?  A faster disk? What is the best choice? The most cost-effective
choice? Who's gonna win the Superbowl? Well, forget the last question.
I was on a roll..... :-)


Thanks for all of the advice, esp. Stephen C. Trier, Aaron Leonard,
Thomas Narten, Anay Panvalkar, Paul Hyder, and Roger-Hunen.

--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
From: jcmorris@mwunix.mitre.org (Joe Morris)
Subject: TELNET terminal types
Keywords: telnet terminal option rfc1060
Organization: The MITRE Corporation
Date: Sat, 9 Jan 1993 18:10:02 GMT

[I haven't been monitoring this group before, so excuse me if this
 is an FAQ...]

I'm looking for some help in resolving a problem of common usage versus
RFC standards in the tcp/ip arena.

Our corporate standard PC-based TCP/IP package (Wollongong's PathWay for DOS)
gives us problems when it is used to attach via telnet to the various UNIX
boxes around the campus.  In particular, in the terminal-type options
negotiation (per RFC 1091) the Wollongong product is delivering the text
string:

    DEC-VT100

(or "DEC-VT220" or whatever) to the host.  Unless I've missed something
this actually does conform to the requirements of RFC 1060 ("Assigned
Numbers") dated 3/90.

The trouble is that none of our UNIX boxes (typically running SUN-OS,
IBM's AIX (RS-6000), or Silicon Graphics' IRIX) have the faintest
idea what to do with this terminal type; their terminfo files expect
something like "vt100".  One problem is that RFC 1060 does not include
any terminal types of the form "VTxxx".

So...any comments?  Is Wollongong alone in adhering to RFC 1060, or do
the UNIX vendors say "RFC's aren't legal standards", or have I missed
some obvious point here?

Joe Morris / MITRE
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: dirk@incom.de (Dirk Koeppen)
Subject: Re: NW 3.11 ODI + PC-NFS + remote boot: is it possible?
Reply-To: dirk@incom.de
Organization: Dirk Koeppen EDV-Beratung, D-6050 Offenbach, Germany
Date: Mon, 11 Jan 1993 01:02:18 GMT

> I want to net boot a discless workstation with the DOS ODI shell
> and also have access to PC-NFS.  I have mucked about with various
> configurations using odinsup but I still can't get NFS to work.
> 

The TCP/IP BOOT-PROM from Carl Schasiepen (+49 2102 4906 0, ask for Rudolf  
Boes) comes with a NetWare NLM which implements TFTP and BOOTP to the 
Netware server.

You can boot from a TCP/IP server or from NetWare using the NLMs and install  
PC-NFS or an ODI workstation. I use it with the EXOS205 because they do not  
have a NetWare PROM for that card.

ciao,
dirk
--
  Dirk Koeppen  -  Holzwiesenweg 22  -  D-6050 Offenbach  -  Germany
  Phone: +49 69 89 3000 - FAX: +49 69 89 3004 - email: dirk@incom.de
  ---
  ** Phase 2 - Check Pathnames
  UNALLOCATED I=2 (NOT EMPTY) REMOVE?
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: grunert@jupiter.rz.Uni-Osnabrueck.DE (Joerg Grunert)
Subject: TCP/IP with XINU
Reply-To: grunert@jupiter.rz.uni-osnabrueck.de
Organization: University of Osnabrueck, FRG
Date: Thu, 7 Jan 1993 11:34:14 GMT

I want to use TCP/IP with the XINU system and a WD8003 Ethernet card.
If you have a source code in C please mail it to me.
It will help me also, when you mail me the Internetaddress of a FTP Server
where I can find the Programms.



Regards
     grunert@jupiter.rz.uni-osnabrueck.de
From: czim@hub.caltech.edu (Chris Ziomkowski)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: TCP/IP on a Novell NE2100?
Date: 10 Jan 1993 09:45:35 GMT
Organization: caltech
Distribution: world
NNTP-Posting-Host: hub.ccsf.caltech.edu

I recently purchased a Novell NE2100 ethernet card which I wish to run
TCP/IP over to connect to my Sun and my Macintosh. I have no desire to run
Novell's Netware at this time. I need to know where I can get software
drivers to allow this. I tried asking the engineer at the place where I
bought the card, and I'm not sure whether he didn't know what TCP/IP was
or if he just didn't speak english well enough to understand my question,
but in any case he was absolutely no help. 

I've been reading a little, and am aware that there is a packet driver
archive at Clarkson. Is this what I need to run the card? If so, specifically
what drivers are required, and how should I go about retrieving and installing
them. 

Thanks for your help,

Chris.
-- 
---------------------------------------------------__-----------------------
 Chris Ziomkowski                                 /  |
 Software Consultant                              |  |           _______
                                              |___|  |____/-|   /  |
 czim@scp.caltech.edu - ---- ---- ---- ---- - *|__|  |____----  \_/
                                              |   |  |    \-|
 "Flying is more fun anyway"                      |  |          --------
                                                  \__|
----------------------------------------------------------------------------
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: a722756@roper.mc.ti.com (W. Donald Rolph)
Subject: Re: NDIS/Netbios
Originator: a722756@roper.mc.ti.com
Organization: Texas Instruments / Attleboro Mass / USA
Date: Mon, 11 Jan 1993 21:04:12 GMT


In article <1993Jan8.130337.9901@informix.com>, christb@infmuc (Christian Barmala) writes:
|> Sorry for that stupid question:
|> Has NDIS something to do with Netbios? Is it the NDIS the low level
|> driver for Netbios?
Probably should be an a FAQ, but I will venture to answer.
 
NDIS is a specification for writing DOS based ethernet drivers to attach to
ethernet hardware boards.

Netbios is a communications protocol for client-server communications developed
by Microsoft.

Netbios can run over a variety of protocols, (e.g. TCP/IP, NBP, netbeui(sp?),
xns, and DECNET to name a few).  The protocol  stack would then be written to
talk to an ethernet card using NDIS, making the protocol stack network card
independent.

Hope that helps.

-- 

Regards.
 
Don Rolph  a722756@pan.mc.ti.com WD3 MS10-13 (508)-699-1263
Xref: sparky comp.protocols.tcp-ip.ibmpc:7354 comp.sys.novell:11346
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject: Re: ODI information requested.
Date: 11 Jan 93 15:58:45 MDT
Organization: Utah State University

In article <1iskr9INNqfs@usenet.INS.CWRU.Edu>, trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
> In article <1993Jan11.200015.26324@novell.com> dmurphy@novell.com 
>(David Murphy) writes:
>>This is the way it was designed and not a bug.  The reasoning being
>>that people would generally only being using a Stack for a certain form
>>of connectivity, eg. TCP/IP from 1 company.
> 
> I think it's more because it's hard to figure out just how to share one
> Ethernet address between multiple protocol stacks.  For example, just
> how would you load more than one IPX for the same Ethernet address?
> 
> The same applies to IP, though there has been a mechanism developed (in
> NDIS) that permits multiple stacks of the same type, as long as they all
> cooperate in a certain way.
> 
> There's more than assumptions here.  Most protocols are not designed for
> more than one stack per Ethernet card, and that makes putting more than
> one stack per card quite hard.  Call it a protocol deficiency if you want;
> that doesn't make it easier.
> 
> -- 
> Stephen Trier                      "We want to offer you a price that you
> Network software type               just can't afford to take advantage of."
> Case Western Reserve University         - Sales blurb from HSC Software
> trier@ins.cwru.edu
-------------
	Close, but not quite the story. Multiple protocols can share a board
with little problem these days, and ODI, NDIS, and PD modules are designed
for this. The difficulty is not sending packets of the same protocol type
from multiple (same type) stacks. The difficulty is, however, receiving packets
when there are contending receipients. A packet will be delivered just once,
but to whom? Well, you can't tell from the outside so one stack gets the 
packet, whether it belongs there or not, and the others starve. Misdelivery
has generally unpleasant conseqences. Delivering the same packet to all 
contenders is misdelivery to N-1 stacks, a worse problem than just one.
	A protocol stack is, for the most part, a decoder and encoder of the
information in a packet, and that's a messy detailed business. ODI, NDIS, PD
are not protocol stacks but are packet handlers of roughly similar nature; 
they are interested in physical addresses and the like rather than the deep
interiors of what one protocol may say. They are good at separating one
protocol flavor from another, because packets are built with this in mind,
but can't distinguish IP for stack 1 from IP for stack 2 etc.
	Take this one step forward. UPD over IP. It's connectionless so no
trail is left about who might want the incoming packet. The trail is an
attempt to track a conversation, a la pktmux. Doesn't work with UPD, and
in many cases it does not work with TCP.
	If you want multiple applications which use the same protocol then
either run them all over the same protocol stack, or get another lan adapter.
	Joe D. 
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: apeltone@smtplink.oulu.fi (Antti Peltonen)
Subject: 3270 (graphics) term. emul. in X11 ?
Organization: ATK-keskus
Date: Mon, 11 Jan 1993 13:53:37 GMT

Hello,

Excuseme if this is a wrong group, but i am not Unix or
X-guru - i am using MS-Windows with HclXceed on PCTCP
(So this is the right group :))

The question:

What I am lookin for is IBM 3270 graphics terminal emulator
for X-windows. (I want to use IBM (GDDM) graphics prgs on my
X-terminal.)

Any information about PD or moneyware appreciated.

antti@phoenix.oulu.fi




Newsgroups: comp.protocols.tcp-ip.ibmpc
From: bcmatusz@vela.acs.oakland.edu (Brian Matusz)
Subject: Windows Sockets ...
Organization: Oakland University, Rochester MI.
Date: Fri, 8 Jan 1993 03:02:47 GMT

Being posted for a friend; followup to center03@cps201.cps.cmich.edu
--------------------------------------------------------------------

I've been looking over the Windows Sockets specification.  Included
is the .DEF file you should use when linking WINSOCK.DLL.  My question
is this ... do the names or the ordinal values matter?  If I use C++ and
it mangles the names, but I leave them in the correct ordinal slot,
is everything okay?

Also ... not entirely sure how this works, but, if I declare a function
as being external "C" in a C++ program, I can still use C++ code in it,
but the name mangling/strict type checking is not enforced, right?
Never had the chance to see what happens with all of this...

Thanks!
Brad Wilson
center03@cps201.cps.cmich.edu
-- 

---
bcmatusz@vela.acs.oakland.edu
"Use DEVICE=EXXON to screw up your environment."
From: mccashin@unixg.ubc.ca (Brian McCashin)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Need help with QVTNet
Date: 5 Jan 93 21:54:24 GMT
Organization: The University of British Columbia
NNTP-Posting-Host: unixg.ubc.ca

In <1993Jan4.142632.14848@miavx1.acs.muohio.edu> dskeeler@miavx1.acs.muohio.edu (Dennis S. Keeler) writes:

>	I've been able to run NCSA Telnet within a DOS Window, but can't get
>QVTNet working. It always says "Network Initialization Error." I've tried using
>both dis_pkt and 3c503 as my packet driver. I've tried calling pktint.com, but
>it doesn't seem to help. I've also tried winpkt.com. NCSA Telnet works with it,
>but QVTNet doesn't.
>	Any tips, samples config.sys/autoexec.bat's, etc. would be appreciated.
>	(Should I be running pktmux, which I just read about a few messages
>ago?)
>	Thanks.
In autoexec.bat load what ever packet driver works with NCSA Telnet and then
pktint.com At least this should get you past the "Network Initialization Error"
into something like host or Gateway not responding.

Brian

PS Send me your *.rc files and I'll take a quick look
-- 
 Brian McCashin                            Internet: mccashin@unixg.ubc.ca
 Senior Programmer/Analyst                 Phone: 604-822-5502
 Centre For Health Services and Policy Research
 University of British Columbia, Vancouver CANADA
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: "Scott Bates Guthery" <p00197@psilink.com>
Subject: FTP & Internet Packages
Reply-To: guthery@slcs.slb.com
Organization: Schlumberger
Date: Thu, 7 Jan 1993 02:59:57 GMT
X-Mailer: PSILink-DOS (3.3)

Recently Mark Bixby posted a list of Internet software packages that
are compatible with FTP's PC/TCP TCP/IP stack.  The list included
trumpet, nupop, dosgofer, oacwais, and achied.  At about the same
time I sent a query to support@ftp.com asking if they had such a list.
The reply I got from FTP was that all these packages would have to
be rewritten to work with FTP's TCP/IP.

Anybody know the real story?  How *DOES* one integrate FTP's
software, the Clarkson drivers, and these packages?  A config.sys
and autoexec.bat example and/or a diagram would be greatly appreciated.

Newsgroups: comp.protocols.tcp-ip.ibmpc
From: mickf@quay.ie
Subject: SNMP Newsgroups ?
Summary: Are there any SNMP Newsgroups ?
Date: Wed, 6 Jan 1993 19:31:13 GMT
Organization: Quay Financial Software
Keywords: SNMP

I am currently working on network management and looking for information.
Does anybody know of any SNMP newsgroups etc. ?

Mick Fleming
mickf@quay.ie
From: steve%cstat.aztec.co.za@ucthpx.uct.ac.za
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Running NDIS-based stack on a packet driver
Date: 11 Jan 1993 12:36:22 -0600
Organization: Compustat (Pty) Ltd
NNTP-Posting-Host: cs.utexas.edu


A plea for help (what else)...  can anyone get me out of this spot? 

In case you don't want to read all the ramble, the main thing that I
(think I) need is:

    - A shim that will connect an NDIS client with a packet
      driver.  I.E. the _opposite_ of DIS_PKT.
OR  - An NDIS MAC driver for Arcnet that does the equivalent of
      ARCETHER, that complies with RFC1201, and works.

Thanks!



Here is the full story...
=========================

I need to get a NDIS-based TCP/IP product talking on an ARCNET network.

The product is the "Reflection Network Series" from Walker, Richer & Quinn.
I have to use this because it supports the proprietary NS/VT protocol
that is needed to log in to our HP3000.


A NetWare 3.11 server gateways IP traffic on the Arcnet over to our
Ethernet.  The Netware server expects IP traffic on the Arcnet to comply
with RFC1201, I believe.

I have no problems Telnetting to our Unix systems using the ARCETHER
packet driver with TN3270, WinQVT etc.


What I have tried
=================

I obtained a NDIS MAC driver for Arcnet, MSARC.DOS.  This describes
itself as "Microsoft ARCnet Driver (c) Copyright 1990 Microsoft
Corporation".  It is dated 1990-11-29.

When I try to ping the Netware server, it does not respond to the
ARP.  Inspection of the packets being transmitted shows that this driver
seems to be encapsulating ordinary DIX-format frames within an Arcnet
frame with protocol byte hex E8.  This is not the RFC1201 format the the
Netware file server is looking for.


My next idea was to use old reliable ARCETHER with a packet-driver to
NDIS shim.  But where to find such a shim??  DIS_PKT does exactly the
opposite of what I want.  But where is the reverse gear... :-) 


The third idea was to go via ODI along these lines:

  ARCETHER   talks to the Arcnet card, converts RFC1201 <-> DIX Ethernet
  LSL        the ODI link-support-layer
  PDETHER    ODI MLID that talks to ARCETHER packet-driver.
  ODINSUP    NDIS MAC driver that talks to ODI

I thought this was *awfully* clever.  Unfortunately (!), PDETHER only
supports the Ethernet_II (DIX) frame format, and ODINSUP requires support
for all the others too (Ethernet_802.3, Ethernet_802.2 and
Ethernet_SNAP).  D*mn.

[ARCETHER from Packet driver release 10; PDETHER v1.01, Nov 01 '91;
ODINSUP v1.21, Nov 13, '92]


This shouldn't be so hard.  Can anyone help??  Please?

Steve

----------
Stephen Davies, Compustat (Pty) Ltd, Cape Town
steve%cstat.aztec.co.za@ucthpx.uct.ac.za



----------
Stephen Davies, Compustat (Pty) Ltd, Cape Town
steve%cstat.aztec.co.za@ucthpx.uct.ac.za
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: richb@jti.com (Richard Braun)
Subject: Re: UTP && THINWIRE same card 
Organization: Jupiter Technology Inc. / Waltham, MA
Date: Fri, 8 Jan 1993 17:17:37 GMT

dold@unislc.uucp (Clarence Dold) writes:
>The one I have is from Allied Telesis, (415) 964-2771, FAX (415)964-0944.
>I clip it right on the back of my system, and it takes a twisted pair
>connection, using normal ether drivers I already had.  $45 quantity 1.

A purchasing manager here at my workplace spotted an ad from Allied
Telesis a few days ago, and is now planning to order their new
AT-1700BT board which has the 10BaseT and BNC connectors.  The
advertised price is only US$99, so it's attractive from that point of
view.

As the person who'll most likely be stuck with any technical problems,
I'm wondering how good this new interface is likely to be?  And will
it likely support the crynwr drivers?  (It comes with NDIS, ODI drivers.)
I noticed the faxed blurb does mention FTP PC/TCP, which is usually based
on the packet drivers.

-rich
From: ashok@biochemistry.cwru.edu (Ashok Aiyar)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Is there a freely distributable CSLIP (or PPP) for IBM PC?
Date: 10 Jan 93 15:20:02 GMT
Organization: CWRU School of Medicine
NNTP-Posting-Host: axa12-slip.dialin.cwru.edu

In article <1993Jan10.073836.6767@blaze.cs.jhu.edu> bogstad@gauss.cs.jhu.edu (Bill Bogstad) writes:

>        Now that I've gotten the lowest level of serial IP connectivity
>working (slip), I'ld like to upgrade.  Is there CSLIP (or compressed PPP)
>software available for use on IBM PCs.  Compatibility with software that
>supports the packet driver spec would be really nice.  I'm not sure how that
>would work though since the packet driver spec seems to be too low on the
>protocol stack to do this easily.  On the other hand, "ethersl" and
>"slip8250" some how manage to work.  Any suggestions or pointers greatly
>appreciated.

The software has to be able to handle compressed SLIP, not the packet 
driver.  For instance Clarkson University TCP (CUTCP) can talk CSLIP.  In 
the CONFIG.TEL file there is an option "vjc=yes/no" (yes would turn on Van 
Jacobson Header compression for compressed SLIP).

Another package is Ka9Q NOS/NET.  These are the only two PD packages that I 
am aware of that handle compressed SLIP on DOS platform.  Undoubtedly there 
are others.

Ashok
----------------------------------------------------------------------
                              Ashok Aiyar 
                      Department of Biochemistry
                       CWRU School of Medicine
----------------------------------------------------------------------
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: jverde@bugs.inescn.pt (Isidro Vila Verde)
Subject: PD exp16 + NetWare Lite ?
Keywords: exp16, LSL, ipxodi 
Organization: Inescn-Redes
Date: Mon, 4 Jan 93 17:08:19 GMT

I am trying share CUTCP or WATTCP and NetWare Lite.
First I am trying this sequence:
      LSL
      exp16 0x61
      ipxpkt
      server
      client
      net login supervisor
on two Pc's, but the net login not see the other Pc.
Second I am trying use odipkt:
	LSL
	exp 0x61
	odipkt 97
and pc get me the message:
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Problems with Dell 466DE, 3c503, and PC/TCP
Date: 12 Jan 93 17:28:21 GMT
Reply-To: jbvb@ftp.com
Distribution: world
Organization: The Internet


    I have a user who just replaced his Compaq 386/20 with a Dell
    466DE (66MHZ DX-2, 16MB RAM, 320MB IDE drive) and who finds that
    his PC/TCP will not work properly on the new machine.  We moved
    his 3c503/16 to the new system, without changing any jumper settings
    (base i/o 310, shared memory disabled) and have removed all other
    add-in devices from the Dell system.
    
    We're using the NDIS drivers, with NDIS-to-packet driver
    (dis_pkt) shim and netbind.  protocol.ini specifies
    interrupt vector 60H; we've tried others with no luck,
    as well as having tried all the hardware IRQ possibilities.
    The 3com board passes all diagnostics.

The problem seems to be related to packets arriving close together,
given that it only shows up during FTP transfers.  Try enabling
shared memory.  No guarantee this will work, since I know of plenty
of board/bus combinations that won't run reliably, but shared memory
sometimes works better.  You might also want to check the version of
the NDIS driver and make sure it's 3Com's newest...

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

Newsgroups: comp.protocols.tcp-ip.ibmpc
From: gooey@helix.nih.gov (Sean Graham)
Subject: (C)Slip/PPP Servers for DOS?
Keywords: slip, ppp
Organization: National Institutes of Health, Bethesda
Date: Wed, 6 Jan 1993 04:39:38 GMT

	I'm now in a nice position of having both SLIP and PPP drivers
	for my Mac's and PC's, but I've got no server.  So I'm looking
	to set up a SLIP or PPP server on a spare DOS PC (or a Mac, if
	I have to).  I've got a spare PC that I can attach a USR HST
	to and am willing to dedicate it to SLIP/PPP or some sort of
	terminal server that will support SLIP/PPP, now I just need to
	know what software (if any?) is available to do this on a PC
	(or Mac, or, but this is pushing it, an Intergraph UNIX box).

	Thanks in advance...

	Sean Graham


--
|| Sean N. Graham                 NIH               DoD# 601  AMA# 601894  ||
|| '91 GSX600FM | '85 RX-7    Bethesda, Md          gooey@helix.nih.gov    ||
|| "This is a test of the Emergency Broadcasting System.  This is just a   ||
|| test.  In the event of a real emergency you would most likely be dead." ||  
Newsgroups: comp.protocols.tcp-ip.ibmpc