HDTenEightyP/NetNews huggingface dataset:
From: wjr@FTP.COM (William J Rust)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: FTP Software e-mail address wanted
Date: 10 Nov 92 20:27:01 GMT
Reply-To: wjr@ftp.com
Distribution: world
Organization: The Internet


    From: "Gary A. Hildebrand" <sun-barr!sh.wide!wnoc-kyo!icspub!oskgate0.mei!chorus.mei!saturn.mew!srl!gah@uunet.uu.net>
    
    All,
    
    I'm looking for the e-mail address for FTP Software Technical Support, if
    it exists.  Judging by their product line and the existence of such
    addresses for other companies (like Borland and Quarterdeck), I suspect
    they do have one.  We just got their 2.1 PC/TCP software, and there isn't
    even so much as a telephone number in their 1000+ page manual.
    
    Thanks in advance,
    
    Gary Hildebrand

Actually, the phone number is there, right on the title page (I
checked to be sure :)). But we do have several email addresses which,
if you are in Japan as your address indicates, might be more
convenient. They are support@ftp.com for support questions,
bugs@ftp.com to report undocumented features and info@ftp.com for
product information. In addition to the phone numbers in my .sig, 508
685 3600 is the direct support line and 508 794 4484 is the support
fax line. Sorry, there is no 800 service, but we also don't have 900
service, so you win some and you lose some.

--
William J Rust (aka, not-the-mama)                       Internet: wjr@ftp.com
FTP Software, Inc.                         (508) 685-4000, fax: (508) 794-4488


Newsgroups: comp.protocols.tcp-ip.ibmpc
From: Hendrik.Klompmaker@beheer.zod.wau.nl (Hendrik Klompmaker)
Subject: Re: BANPKT: YAPS (yet another packet shim)
Organization: Wageningen Agricultural University
Date: Thu, 12 Nov 1992 20:45:45 GMT

In article <2086@hsdndev.UUCP> ddl@hsdndev.UUCP (Dan Lanciani) writes:
>Path: sun2.iend.wau.nl!sun4nl!mcsun!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!hsdndev!ddl
>From: ddl@hsdndev.UUCP (Dan Lanciani)
>Newsgroups: comp.protocols.tcp-ip.ibmpc
>Subject: BANPKT: YAPS (yet another packet shim)
>Message-ID: <2086@hsdndev.UUCP>
>Date: 10 Nov 92 03:07:22 GMT
>Article-I.D.: hsdndev.2086
>Organization: Harvard University, Cambridge MA
>Lines: 9
>
>	BANPKT provides a packet driver interface over Banyan's VINES
>network drivers.  Usage is similar to ODIPKT: a single optional argument
>specifies the packet vector in decimal.  Version 1.0 beta is now available
>for anonymous ftp in put/banpkt on hsdndev.harvard.edu.  It has been tested
>in a WD8003 configuration only; please let me know if there are problems.
>
>				Dan Lanciani
>				ddl@harvard.*
Hi Dan,

I tried to get your driver running but no succes yet. The first that comes 
to mind is that I don't know how to implement it. I looked through the 
ODIPKT driver stuff in pdether.zip but found little usefull information.
So please help.
After I load the native Banyan drivers I should load the banpkt driver Yes??
if so I should supply an interrupt so I would think banpkt 0x60 should work.
I tried this with the decimal equivalent as well but no respons. The machine 
hangs. Once the prompt returned but no packet driver was loaded.
I've been fooling around with the Crynwr packet drivers a lot so I think I 
should be able to tell if they work or not but I'm in the dark here.
Questions are: What am I doing wrong (3c503 NIC, Vines 4.11(5)).
               Do I need a net.cfg and if yes (which I doubt :)) what should 
	       be in it.

Bye Hendrik

===============================================================================
|******** Wageningen Agricultural University. Animal Production Group ********|
-------------------------------------------------------------------------------
Hendrik Klompmaker		Internet : Hendrik.Klompmaker@Beheer.Zod.Wau.Nl
System Manager			Bitnet	 : KLOMPMAKER@HWALHW50.BITNET
Phone : +31 (0)8370-83934	Fax	 : +31 (0)8370-83962
Snail : Marijkeweg 40, 6709 PG	WAGENINGEN, The Netherlands
===============================================================================
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: donp@novell.com (don provan)
Subject: Re: Fragmented IP packets: any PD implementations?
Keywords: IP fragments TCP/IP
Organization: Novell, Inc., San Jose, California
Date: Thu, 12 Nov 1992 22:32:15 GMT

In article <BxM5tu.Jws@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
>As you may have known, I initially wrote much of
>my TCP without a real network around...

What a coincidence!  Me, too!  (Of course, in my case it was because
at the time there was no real TCP/IP network *anywhere*....)

>A very common oversight from practically everyone who answerred was the
>assumption that using 576 byte packets is the answer.

To be honest, i've found that it's usually counter productive to bring
up networks with MTUs smaller than 576.  It's typically very hard to
change the mind of someone that's convinced 576 is the minimum legal
MTU, and someone like yourself that understands what the 576 byte
limit really means don't need to be reminded of smaller MTUs.

>I believe that the RFCs recommend against router reassembly, however it is
>never listed as verboten, just impractical.  The only statement I can find
>is in RFC 1009:

OK, you caught me.  I was being vague not because i don't have a
specific reference, but because the reference is rather complicated.
The reference is Almquist, P., Editor, "Requirements for IP Routers",
Internet Draft (draft-ietf-rreq-iprouters-03.txt), October 1, 1991.
As far as i can piece together, about a year ago when this draft was
released, it was on the verge of being published as the RFC replacing
RFC-1009.  Suddenly, all interest in it was lost and the RFC was never
published.  I don't know what the deal is, but i still use it as the
latest thinking in router requirements.  The applicable quote from
page 62 of that document follows:

         4.2.2.7  Reassembly: RFC-791 Section 3.2

           As specified in Section 3.3.2 of [INTRO:2], a router MUST
           support reassembly of datagrams which it delivers to itself.

           A router MUST NOT reassemble any datagram before forwarding
           it.

           DISCUSSION:
                A few people have suggested that there might be some
                topologies where reassembly of transit datagrams by
                routers might improve performance.  In general,
                however, the fact that fragments may take different
                paths to the destination precludes safe use of such a
                feature.

                Nothing in this section should be construed to control
                or limit fragmentation or reassembly performed as a
                link layer function by the router.

So that's my justification for saying that reassembly by routers is
forbidden.
						don provan
						donp@novell.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: res_ewv@exodus.valpo.edu
Subject: Help needed with NCSA and Novell LAN
Organization: Valparaiso University
Date: Thu, 12 Nov 1992 18:18:19 GMT
X-Posted-From: exodus.valpo.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

Hello,

I am a student at Valparaiso University who is working with our local LAN
manager to try to accomplish the following:  What we need to do is have NCSA
Telnet running on the stations of our local Novell File Server. The Novell
server is then on our campus backbone.  From what I understand, what we have to
do is the following:  run IPX and IPXPKT.COM on each station, and run IPXPKT
and NET.EXE (which provides the routing) on the fileserver.  Is this correct? 
Any help from anyone who has set up a similar system would be greatly
appreciated.

By the way, I was able to set up NCSA using the drivers for the ethernet card,
and all works fine as long as IPX has not been installed, but once it has been,
NCSA no longer works.

Thanks in advance for any help you can offer.
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: satam@saathi.ncst.ernet.in (Kirtikumar G. Satam)
Subject: Info Needed on TCP/IP developer's S/W on DOS
Followup-To:  satam@saath.ncst.ernet.in
Keywords:  TCP/IP, DOS, sockets
Organization: National Centre for Software Technology, Bombay, India.
Distribution: world 
Date: Fri, 13 Nov 1992 06:31:42 GMT


Hello everyone,

	pardon me if this has been asked. Please send e-mail replies.

I am looking for a TCP/IP package (public domain or commercial) which
has following functionalities.

1. Should be able to run on Packet Drivers as well as on PKTMUX.

2. Should provide a sound programming interface, preferably standard one
   such as  BSD sockets. So that code written on BSD systems is easily
   portable.

3. We are not really interested in how good it provides utilities such
   as telnet, ftp etc. NCSA as well as CUTCP serve our purpose.

we are basically R&D institution with a thrust on development of network
applications, what we need is a good developer's interface.

PS: Windows support is not essential, though it is welcome.

Please send mail to

	satam@saathi.ncst.ernet.in

with you information.

Thanks a lot.

	- satam.
From: bill@solaria (Bill Neisius)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: SLIP connection to XYPLEX on modem
Date: 6 Nov 92 03:48:06 GMT
Reply-To: bill@solaria.hac.com
X-Newsreader: TIN [version 1.1 PL6]


OK, I give up. 

I'm trying to connect a modem to a XYPLEX 1500 server....
and run SLIP.  It works fine when I connect the local ISBN phone 
network to the server; but when I connect a modem, all I get on the
remote machine is 'bad IP checksum' or 'can't open connection, timeout'.

I'm using SLIP8250 and TELBIN on the remote PC; modem on the server is
a MultiTech v.32, on the PC it's a DigiCom Scout+.  Connection is at
9600 baud/V42.

I can see 'ping' packets arrive at the PC, but something is missing
'cause they generate 'bad IP checksum' in TELBIN.  If I try to open
a connection, I get a 'timeout' almost immediately... 

So what's the deal?  Flow control?  The XYPLEX has only 8 wires in its
serial connection, so you get DCD/DTR or CTS/RTS, but not both. Does
SLIP work with XON/XOFF?  well...I guess so, cause it works with the
ISBN 'modem'....

Any suggestions?

Bill Neisius
bill@solaria.hac.com
From: backman@FTP.COM (Larry Backman)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: PC-NFS 4.0 and IBM TCP/IP 1.2.1 for OS/2 problems
Date: 9 Nov 92 00:14:59 GMT
Distribution: world
Organization: The Internet


 >> 
 >> I am trying to access an OS/2 2.0 NFS server (IBM TCP/IP 1.2.1 for OS/2)
 >> from a DOS 5.0 PC running Sun PC-NFS 4.0. I can mount drives from the
 >> OS/2 server, but when I do a dir I get names that look like...
 >> 
 >>         WINWO~7A     <DIR>     04-14-92   9:06a
 >> 
 >> when they should look like...
 >> 
 >>         WINWORD  DSK <DIR>     04-14-92   2:06a 
 >> 
 >> (notice the time stamp is wrong also)
 >> 
 >> In fact the only file or directory that has a extenstion is a WINA20.386 
 >> but even it is displayed as WINA2~HA.386.
 >> 
 >> You can cd to a directory if you know the name (not the dir displayed
 >> mangled version).
 >> 
 >> You cannot execute .exe files but you can type autoexec.bat, for example.
 >> You can copy files from DOS to NFS server, but you cannot copy from the
 >> NFS server to DOS (says file not found).
 >> 
 >> Can anyone shed some light on this problem. When I called Sun, all I got
 >> was a "we didn't test with that software" answer.

We did test with that software :-).  We know all about this...

OS/2 has the endearing feature of providing 2 different file systems, FAT
& HPFS.  FAT looks and acts like DOS, with 8.3 uppercased filenames.
HPFS is roll your own, case-insensitive and relatively length and format
insensitive.  IBM's NFSD simply reflects what it finds to an NFS client;
if it finds a FAT file system you get:
	WINWORD.DSK
   &    WINA20.DSK

if its HPFS & your lucky you get lower cased file names.

PC-NFS & its copycats defines an algorithm for mapping foreign filenames
to DOS 8.3 uppercase format using the twiddle (~) as a mapping
indicator.  The algorithm assumes that lower case filenames are nromal
and uppercase file names are foreign; thus the mapping of WINWORD.DSK
to WINWO~7A.

PCTCP is programming around the OS/2 server's feature by adding a
parameter by which all upper case files can be converted to lower
case instead of mapped.  I'm sure if you ask loudly enough at Sun
that the PC-NFS group has come up with much the same solution by now.
Its not hard; its just 1 more check, a function call, and the
accompanying performance hit.

On the other hand; you could also push at your IBM rep. and have them fix
their server such that upper cased FAT file system names can be configured
to be reflected out on the net as lower case.

Thats life in the big-city...

Whats actually an interesting sales point is the fact that IBM's OS/2
NFSD is over a year old and this is the first time this well-known
issue has been brought up on this august mailing list.  Hmm....maybe
I ought to got get a 16-Meg 486 with a CD-ROM and become an NT expert :-)



Larry Backman
FTP Software

Newsgroups: comp.protocols.tcp-ip.ibmpc
From: hooper@ccs.QueensU.CA (Andy Hooper)
Subject: Re: Fragmented IP packets: any PD implementations?
Keywords: IP fragments TCP/IP
Organization: Queen's University, Kingston
Date: Fri, 13 Nov 1992 13:28:29 GMT

In article <1992Nov12.223215.5263@novell.com>, donp@novell.com (don provan) writes:
...
| The reference is Almquist, P., Editor, "Requirements for IP Routers",
| Internet Draft (draft-ietf-rreq-iprouters-03.txt), October 1, 1991.
| As far as i can piece together, about a year ago when this draft was
| released, it was on the verge of being published as the RFC replacing
| RFC-1009.  Suddenly, all interest in it was lost and the RFC was never
| published.  I don't know what the deal is, but i still use it as the
| latest thinking in router requirements.

Probably the bright lights that would have contributed to it got caught up in
saving the Internet from it's own success. The discussions about the successor
to IP Version 4 have consumed much energy from a lot of talented people.

Andy Hooper

Newsgroups: comp.protocols.tcp-ip.ibmpc
From: dblack@ccla.demon.co.uk (David Black)
Subject: No subject
Organization: Crucible Computers Ltd.
Date: Tue, 10 Nov 1992 21:44:05 +0000

TCP/IP Packet analyser

Is there a Public domain IP packet analyser that I can run on a
PC through the packet driver i/f. I need it for debugging purposes.

/Dave Black
=
David Black             49 Woodgrange Drive     dblack@ccla.demon.co.uk
Crucible Computers      Southend On Sea         dblack@cix.compulink.co.uk    
Networking Consultant   Essex UK SS1 2SD        Flies AA5B G-NGBI
                                
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: uad1216@dircon.co.uk (Hugh Neale)
Subject: Re: 4100/4200 Tek emulator Needed
Date: Wed, 11 Nov 1992 17:33:27 GMT

In article <921103144056.31c09502@VAX5.CSD.COM> HENDERSON@VAX5.CSD.COM ("Phil Henderson: Bldg. 050/170, x4977") writes:
>Question:
>---------
>The other is TEEM-TALK by PERICOM PLC.  This also works as a serial or network
>emulator.  We have had a couple of copies for a couple of years.  There seems
>to be some difficulty in setting this up, but I haven't done it personally. 
>Later versions may be improved.  I have a phone number in New Jersy:
>  (609)895-4040... I haven't called it lately, so I'm not sure if its still
>active.   
>
>I don't know of the cost of either package.
>
>Phil Henderson,
>Manager, Engineering Computing
>United Technologies, Chemical Systems
>


Pericom now produce TEEM-X, available on all of the major UNIX
platforms.  It works very well in Tek mode.  I believe a DOS 
Windows version is coming soon as well.
Ian Wade
Open Systems Consultant
Shell UK
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: byron@cc.gatech.edu (Byron A Jeff)
Subject: NE2000 jumper question
Keywords: NE2000 jumpers HELP!
Reply-To: byron@cc.gatech.edu (Byron A Jeff)
Organization: Georgia Institute of Technology
Date: Fri, 13 Nov 1992 19:01:14 GMT

I borrowed an NE2000 card to do some packet driver experiments. Unfortunately
the owner can't locate the documentation. 

The card is made by Novell and is 16 bit. It has 4 sets of jumpers.
The first set (W1-W8) obviously sets the output mode (AUI .vs thinnet) and
is set for thinnet. 

The second set (W9-11) has 9 and 10 set and 11 open. It probably sets the 
IO address but without the docs it's impossible to tell which. 

The next set (12-15) has a single jumper (12) set. It's probably the interrupt 
jumper but which interrupt? 

The last lonely one (W16) is currently set. My guess is that it selects 
the boot bios EPROM (which is not onboard - there is an empty socket). 

So might anyone out there have any info on which settings mean what?

I appreciate any help you can give.

BAJ
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: steven@unipalm.co.uk (Steven Vincent)
Subject: Re: logging session with tn3270
Organization: Unipalm Ltd., 216 Cambridge Science Park, Cambridge CB4 4WA, UK
Date: Tue, 10 Nov 1992 18:17:12 GMT

brigitte@cismbk.univ-lyon1.fr (brigitte KIEFFER) writes:

>Hello,
>I am looking for a tn3270 for DOS with whom I can log sessions,
>or with whom I can enable a capture mechanism during a session.
>I have already tried two products: neither PathWay Access nor PC/TCP
>can do it.

PC/TCP's tn from at least version 2.05 can log sessions to a file
open a session and enter the following sequence:
F10 o <filename>

all data will be sent to the file specified.

>Does someone know if such a tn3270 exist ?
>Sincerely,
>--
>Brigitte Kieffer. Universite Lyon I , France.

Steven Vincent		steven@unipalm.co.uk
From: johnson@TIGGER.JVNC.NET ("Steven L. Johnson")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: CryNwr EtherSlip & Slip8250
Date: 7 Nov 92 01:27:52 GMT
Article-I.D.: tigger.199211070127.AA09266
Distribution: world
Organization: The Internet

Joe D. writes:

> Peter,
> 	I think bootp is a moot point on SLIP. There is no MAC address for
> the requester on a serial line and that makes life a little difficult for
> the Bootp server to find an address in its tables.

It is my understanding that in order for bootp to work on a slip
connection the equipment terminating the SLIP link on the 'server'
side must have some special support to map a physical port to
an IP address and either alter the bootp request to include the
IP address or be the bootp server itself.

For example on the cisco terminal server that I connect through,
if the request does not contain an IP address it processes it itself,
otherwise it forwards the request out the ethernet port on the
other side to see if any other bootp servers want to respond with
additional information.  In this case it can take two requests to
fully configure.

> 	At least in the Kermit code Bootp is stubbed off when SLIP is
> active, since there is no physical layer addressing involved.

Some people would find it valuable to have it left on.  What's the
harm?

>	Joe D.

-Steve
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: larsent@ucsu.Colorado.EDU (LARSEN  TORE HOIVAAG)
Subject: Mail reader for WIN3 wanted!
Organization: University of Colorado, Boulder
Date: Tue, 10 Nov 1992 20:38:18 GMT

Hi.
Do anyone know of a Win3 mailreaders that can be found
on ftp-sites?
Please respond to gropu or directly to me by eMail.

Tore
larsent@ucsu.colorado.edu

Thanx :)
From: leisner@wrc.xerox.com ( Marty Leisner)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Wanted: PD NFS client for DOS
Date: 11 Nov 92 14:55:12 GMT
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
X-Newsreader: TIN [version 1.1 PL6]

ccdps@levels.unisa.edu.au wrote:
: 
:   Excuse me, but isn't SOSS more or less what the original poster was looking
:   for? And whether or not this is the case, if you want to get some idea of
:   what is involved with writing a NFS, try eavesdropping on the network
:   channels of the Linux project.

No, SOSS is a server, not a client (I've never used PC NFS)..
This is what I understand...

And  I think it is far more useful to have PC NFS clients, and server from
Unix machines (they have an account system and 3 timestamps).

--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: news@usenet.ucs.indiana.edu (USENET News System)
Subject: qvtnet 2.85
Organization: Indiana University
Date: Wed, 11 Nov 1992 06:50:17 GMT

I just ftped the file from cica under util. It works fine.  I have never
before succeeded in using the news reader part of the program.  This time
it runs like magic.  I am actually using it to post this message.

BTW, there seems to be verson 3.0 in the uploads dir on cica.  But it is
apparently corrupted.

Newsgroups: comp.protocols.tcp-ip.ibmpc
From: rivero <rivero@cc.unizar.es>
Subject: ShineNet drivers dont follow standard
X-Xxdate: Wed, 4 Nov 92 20:55:59 GMT
Organization: fisica teorica UZ
X-Useragent: Nuntius v1.1.1d12
Date: Fri, 6 Nov 1992 19:58:32 GMT

We were trying to use PKTMUX with a Shinenet 16 bits ethernet card 
to run two tcp apllications under windows and we have found the 
first problem before to begin. PKTMUX relies on a identification as
PKTDRV which the Shinenet Driver doesnt follow. And to specify
directly the interrupt address seems not to work, so perhaps any 
other thing is violated. 
Before blaminf of shinenet (it works well with PC TCP, and 
is compatible with QvtNet - with a mortal slowing down problem I
have been unable to solve, thought), I wonder if anyone has
found a workaround for this problem... any idea?

Alejandro RIvero
rivero@cc.unizar.es
Zaragoza Univ, Spain
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: dirk@incom.de (Dirk Koeppen)
Subject: Re: Need Packet Driver for MCA card
Reply-To: dirk@incom.de
Organization: Dirk Koeppen EDV-Beratung, D-6050 Offenbach, Germany
Date: Tue, 10 Nov 1992 16:59:29 GMT

Mark Tayler writes
> I am having a problem configuring my ethernet card on a PS/2 model 80
> I have an SMC 16 bit ethernet card.
> 	8013WP/A

The WD8003E does not support the SMC8013/A but it supports the WD8003/A.
This is because the 8013/A has diffenrences in the shared memory and i/o port  
coding of the configuration registers. 

I started to change this but I do not have my PS/2 by hand right now.
If someone else wan't to fix the packed driver right now, I would email
the new configuration register settings. Otherwhise I will post the fix
withing the next two weeks.

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?
From: johnson@TIGGER.JVNC.NET ("Steven L. Johnson")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Fragmented IP packets: any PD implementations?
Date: 13 Nov 92 00:43:37 GMT
Organization: The Internet

Stephen C. Trier writes:
> 
> In article <BxH4xy.Euu@cantua.canterbury.ac.nz> davis@chem.canterbury.ac.nz writes:
> >try ftping from Mac's on appletalk talking MacTCP via a pcrouter - or using
> >slip , both of these result in fragmentation.
> 
> I've been fortunate enough to avoid the former, and the latter is a myth.
> SLIP causes fragments on TCP connections only if the SLIP connection is
> poorly configured.

Unless you include any SLIP configuration with an MTU < 576 as
poorly configured, how does a host guarantee that a TCP datagram
does not fragment on an intermediary SLIP hop?  My understanding
is that probes that determine minimum MTU end to end are not
a host requirement.

-Steve