HDTenEightyP/NetNews huggingface dataset:
From: ant@brolga.cc.uq.oz.au (Anthony Murdoch)
Subject: IBM LAN Services over TCP/IP (was Pathworks for OS/2 v2, for OS/2 v2)
Organization: Prentice Centre, University of Queensland
Date: Tue, 7 Apr 1992 02:31:58 GMT


I was wondering if it is possible to get IBM's LAN services to use IBM's
TCP/IP package to send out LAN Manager requests using the TCP/IP protocol
as a transport.

REASON - We are prodominantly a DEC site here, using Pathworks as the
major LAN software.  Our VAX servers all run Pathworks for VMS (or maybe
Ultrix) and usually UCX (tcp/ip).  So, the servers can receive Lan Manager
requests using either decnet or tcp/ip as the transport (or so I am told
by the guy at DEC).  So, if I can get IBM's LAN requester to send its
Lan Manager requests using tcp/ip, then I should be able to get it to
connect to the Pathworks server.

This I need because DEC may take some time to get the Pathworks client to
work with v2.0 of OS/2.  If I can get the above to work I have the
functionality that I need.

I haven't got the IBM LAN package as yet, I want to know if it is possible
to use it before I go out spending money (as I did with Pathworks :( )

SO, has anyone tried this ?  Where you successful ?

Thanx in advance
ant
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: fighting over the ethernet card...
Date: 6 Apr 92 19:26:01 GMT
Reply-To: jbvb@ftp.com
Distribution: world
Organization: The Internet


            sjf-lwp.novell.com:odi/pdether/pdether.zip

This lets Netware (or anything else that uses ODI) use a Packet Driver
instead.  If you want to use an ODI driver instead, Wollongong, Beame
& Whiteside, Novell and FTP Software all have packages that support
ODI.  Dan Lanciani has also put an ODI-Packet Driver shim out as
freeware.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

Newsgroups: comp.protocols.tcp-ip.ibmpc
From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Subject: Re: PKTMUX issues
Organization: University of Waterloo
Date: Mon, 6 Apr 1992 03:53:57 GMT

"Roger Fajman" <RAF@CU.NIH.GOV> writes:
>
>   Is there any inherent reason why it can't be made to work if the
>   different TCP/IP stacks have different IP addresses?  Admittedly that's
>   wasteful of addresses, but would it work?
>

Yes it *CAN* work.  I had to do this for a while and built it into the
packet driver as the driver was also a proprietary thing.

In theory it works for everything except the "discover myself" protocols
such as RARP and BOOTP.  In practice there could be some problems with
Wollongong's and (I believe) Beame&Whiteside's stacks. If memory serves me
correctly, they both attempted to chain to the hardware interrupt and
may cause some problems resulting from timing and packet arrivals. See
below for more problems.

Also note that some stacks take over a large number of interrupts and
may cause conflicts whether you use PKTMUX or even two separate cards
and packet drivers.

john romkey writes:
>And of course, you'll likely lose if one stack
>tries to talk IP to the other one, but that doesn't seem to be too
>likely an issue on a PC.

That is easy enough to spot and handle in memory.  Likewise, broadcasts
from one must be upcalled to the other.  Here the above mentioned
commercial stacks hurt again because they don't process the packets
from the arrival queues, they require the additional chained upcall,
so your packet demultiplexor must due the stupid act of performing 
a software IRQ just to get those stacks to process the packets. 

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
From: WAHL@UWSTOUT.EDU
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: de201 and de212 packet drivers
Date: 15 Apr 92 14:51:00 GMT
Distribution: world
Organization: The Internet


I am trying to find packet drivers for Digital DE210 and DE212 Ethernet
boards.  All I have been able to find is drivers for DEPCA.  Is this the
driver to use for these cards?  I have tried this driver for the DE201
but haven't had any luck as yet.  The card does work with Pathworks and 
the packet driver shim, but a department here is planning to use Novell
only.  Any guidance will be appreciated.

Thanks
----------------------------------------------------------------------------
Douglas J. Wahl                            INTERNET:	WAHL@UWSTOUT.EDU
Systems Programmer                           BITNET:	WAHL@UWSTOUT.BITNET
University of Wisconsin - Stout            
Administration Building Room 18
Menomonie, WI  54751
From: PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re:  8-bit
Date: 9 Apr 92 15:04:35 GMT
Organization: University of Liege (Belgium), SEGI (Computing Center)

On Fri, 27 Mar 1992 13:01:17 PST Greg Small said:
>= From pcip-request@louie.udel.edu Fri Mar 27 10:05:29 1992
>= From: Andr'e PIRARD <PIRARD@vm1.ulg.ac.be>
>= I just wonder what's the point of the RFC and why the need for BINARY
>= option.  If you don't want to use 8-bit characters, you just don't type
>= them.  Should any party be hurt by receiving 8-bit, it filters them out or
>= strips the 8th bit in pure self-defense attitude.  So, there are 7-bit and
>= 8-bit clients and hosts.  And any user promptly realizes a bad match.
>
>Well not exactly.  There are times when one or the local host may want to know
>if the remote host expects all eight bits to pass.  For example, should control
>characters with the eighth bit set be treated as data or control?  The text
>mode
>says strip the eighth bit.  The user terminal may need the local host to
>provide
>parity for terminal i/o but want a a full eight bit stream for an attached
>device or a data capture.  The remote host knows which is currently required,
>the local host is just a conduit.

In ISO 8859-x, 80-9F are control characters and the extra characters are
above. I feel sad that some joker reserved 32 more control characters when
just a few of the former 16 are useful by these days, but it's the way it
is and the solution to any vt220 terminal emulation: the terminal may always
see 80-9F as controls (if they're really thought useful) and 90-FF as 8-bit
data. And that's why it's a bad idea to use the PC code on Unix.
And one may still use the BINARY option for what's really binary or passthru.

Look. I've been using IBM's TCP/IP for DOS emulator with any host in sight,
8 or 7 bits. Not a glitch -- bugs alone--. They say: if you want ISO 8859-1
complete, start Telnet under chcp 850. Dot. No setup, straight, efficient.
And I am almost sure they don't negotiate binary.
On the other hand, I've tried Novell Lan Worplace's tnvt220.
Pages full of what you get with what active codepage, you have to setup binary
mode, Multinational Terminal etc...
After doing this, on AIX the Return key displays ^M, Ctrl-Return does EOL
but the EOL from the remote host produces a linefeed and the characters
step down to pile against the screen right edge. On SunOS, the result is
even more drastic: Return disconnects the session.
See the mess I and they are in, versus simplicity?

Andr.
From: jbreeden@netcom.com (John Breeden)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re:  IBM LAN Services over TCP/IP (was Pathworks for OS/2 v2, for OS/2
Date: 17 Apr 92 14:56:32 GMT
Organization: Netcom - Somewhere in the S.F. Bay Area

In article <1992Apr16.220533.3798@novell.com> donp@novell.com (don provan) writes:
>Forgive my ignorance, but i've been under the impression that very few
>Netbios over TCP/IP implementations could talk across an IP internet.
>(I.e., i thought most implementations were B-nodes, and that P-node and
>M-node implementations were still rare.)  Admittedly, i haven't been
>paying much attention to the issue.  Do most Netbios over TCP/IP
>implementations nowadays include P-node support?

You're right Don, most (meaning all but one as far as I know) are B node
implimentations (UB being the exception - they have a P node - for the
price of a small Porche).

Most of the B nodes have some sort of mechanism for routing to devices on the
other side of of routers - usally a static NB address to IP address table
(geez - there's that ol' static table again Don :-).

-- 

 John Robert Breeden, Hughes Lan Systems
          jbreeden@kailua.hls.com, johnb@hls.com, jbreeden@netcom.com

 ------------------- cut here and you'll break your monitor -------------------

      "The nice thing about standards is that you have so many to choose 
      from. If you don't like any of them, you just wait for next year's 
      model."
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: cs911212@ariel.yorku.ca (RICK DILORENZO)
Subject: Lantastic NetBios
Originator: cs911212@c11.ariel.yorku.ca
Organization: York University, Toronto, Canada
Distribution: york
Date: Fri, 10 Apr 1992 20:15:21 GMT



I have a MS-DOS network using Lantastic 4.0 with 16-bit Ethernet cards
(using Lantastic's NE2000 drivers) can I have a Unix Server on the network
with TCP/IP ? (so users from the dos nodes can login to the unix server and
be in the unix environment).  Lantastic is a Netbios based Lan.  
I haven't been able to get much support or help in my area with Lantastic.
Do I have to switch to Novell or can I run something concurrently with
Lantastic?
From: EXTUNIV@CCIT.ARIZONA.EDU
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: (none)
Date: 15 Apr 92 20:59:00 GMT
Article-I.D.: CCIT.01GIVNA3MD6C8WWGC6
Organization: The Internet

signoff
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: rlm@sunlight.Physics.UIowa.Edu (Robert Mutel)
Subject: Can Novell Lite and NCSA TCP co-exist? 
Keywords: Novell Lite, NCSA
Organization: Department of Physics and Astronomy, University of Iowa
Date: Wed, 15 Apr 1992 13:25:41 GMT

Sorry if this has already been asked - We just received several copies of Novell
Lite 1.0 and installed them on Gateway 486-33 with Elite-16 Ethernet cards. After
installation, none of the NCSA stuff (Telenet,FTP,finger,etc) works anymore. Is
there some way to set things up so both Novell Lite and NCSA can share the Ethernet amicably? (I had called Novell before purchase and got a 'probably will
work' answer, but nothing definite).

Thanks,
-- 
Robert Mutel
Department of Physics and Astronomy
University of Iowa
Iowa City IA 52242

Telephone: 319-335-1950      FAX: 319-335-1753
Email: rlm@sunlight.physics.uiowa.edu  (internet) 
       iowa::rlm (span)
From: hughes@logos.ucs.indiana.edu (larry hughes)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re:  suggestions for PC based print solutions
Date: 9 Apr 92 19:13:00 GMT
Article-I.D.: bronze.1992Apr9.191300.15909
Organization: University Computing Services News

In article <1992Apr7.211836.10491@uwm.edu>, anthony@csd4.csd.uwm.edu (Anthony J Stieber) writes:
  A free, resident lpr client for MS-DOS doesn't seem to exist, although
  there are free non-resident clients and servers.

NMG-PRN is a TSR and it's free (although source is not distributed).  It 
runs on the FTP Software TCP/IP stack.  It was written in C, so it does
need more memory than one written in assembly, but it does work fine
nonetheless.   I believe there's a copy on Simtel20 and several other
servers as well.

 //======================================================================\\
||      Larry J. Hughes, Jr.       ||          hughes@indiana.edu         || 
||       Indiana University        ||                                     ||
||  University Computing Services  ||   "The person who knows everything  ||
||   750 N. State Road 46 Bypass   ||      has a lot to learn."           ||
||     Bloomington, IN  47405      ||                                     ||
||        (812) 855-9255           ||   Disclaimer: Same as my quote...   ||
 \\======================================================================//
From: CBA012@nvl1.hrz.uni-dortmund.de (Wilhelm Becker)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: ODI driver for WD8013EPC
Date: 9 Apr 92 19:54:57 GMT
Article-I.D.: nvl1.MAILQUEUE-99.920409171439.480
Organization: The Internet
X-Unparsable-Date: 9 Apr 92 17:14:39 MET-1

I just got a new ethernet card from SMC (former WD). When starting the
ODI driver that was delivered with the card, it gives an error message
"unknown board ID" and does not work. The driver is SMCPLUS V2.00 and the
label on the card says
           8013EPC  BD1  0692
     61-600406-002  MADE IN IRELAND

Does anyone know of a newer ODI driver that supports this card?

    Many thanks in advance


   Wilhelm Becker                      Phone: +49 231 755 2098
   Hochschulrechenzentrum                Fax: +49 231 755 2731
   Universitaet Dortmund            Internet: cba012@nvl1.hrz.uni-dortmund.de
   Postfach 500500               EARN/BITNET: cba012 at ddohrz11
   D-W-4600 Dortmund
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: mtcusa@tigger.jvnc.net (Multilingual Technogies Corporation)
Subject: Trouble with NCSA TCP/IP
Originator: mtcusa@tigger.jvnc.net
Organization: JvNCnet, Princeton University, NJ
Distribution: usa
Date: Wed, 8 Apr 1992 17:30:38 GMT

TO:    Anyone
FROM:  Mark Zeiger   mtcusa@tigger.jvnc.net
DATE:  April 8, 1992
RE:    Trouble with NCSA Telnet for MS-DOS

We are trying to set up IBM compatible PCs to talk with our SCO Unix
TCP/IP network.

HARDWARE:
    Fountain 486/33 ISA with 512K VGA
                  or
    Fountain 386/33 ISA with 256K VGA

    SMC (aka Western Digital) 8003E Ethercard PLUS Elite with settings:
        Software setting:   Int 5    I/O Addr 0x240   Base Mem 0xce00:0
                                  or
        Hardwire setting    Int 5    I/O Addr 0x300   Base Mem 0xca00:0

        Thin COAX

PROBLEMS:
    1. Can not communicate with any SCO Unix system on network. NCSA
       Telnet will not recognize any systems.

    2. Hooked up two computers running NCSA Telnet only and isolated from
       rest of network. Left one computer in server mode. When I tried to
       connect with other computer using NCSA Telnet, server showed message:

             Packet received for invalid port -- reset sent
                 Port 23

       Server remained in server mode and second computer retruned to DOS.

    3. ON 486 ONLY - when exitting NCSA Telnet, all screen functions lost.
       Computer is active (i.e. DIR A: shows floppy being accessed), but I
       must reboot computer to regain display.

OBSERVATIONS:
    1. Using PKTALL showed packets being received by NCSA Telnet when it
       was pinged from a SCO Unix computer.

    2. All problems were consistent no matter what combination of hardware/
       software settings were used (except for problem 3 naturally).

If anybody has any suggestions, we would really appreciate your help. Please
respond via email to Mark Zeiger at mtcusa@tigger.jvnc.net or we may be
reached locally if you're in New Jersey at Multilingual Technologies
Corporation at (201) 808-3344.

Thanks
From: turnerj@cpva.saic.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Question Re: Clarkson University TCP and config.tel
Date: 14 Apr 92 16:16:27 GMT
Organization: Science Applications Int'l Corp./San Diego

In article <92105.004929K3006E7@ALIJKU11.BITNET>, K3006E7@ALIJKU11.BITNET
writes:
  
  >Warning, packet driver vector invalid, using default search
  >
  >and then on the next lines:
  >
  >Packet Drive (NE2000)
  >Class 1 Type 54 Version a Extended 2
  >etc.
  >
  .....
  >
  >hardware=packet; interrupt=3
  >
  >Should it be something else?  Also, do I need to set "address"
  >and "ioaddr", or are the defaults already okay.
  
 The docs say that cutcp looks for the packet driver between interrupt vectors
 60 and 69(?) in its default search.  I have a 3c507 driver loaded at 7E so the
 default search, of course, fails and gives me the same error message that you
 have identified.  However, irrespective of messages fed back, the program
 finds the driver and proceeds without error.  Sometimes, I'll load the driver
 at INT 60 or INT 61 with the same results, i.e. error message but no real 
 error.  I guess somebody else with a different kind of intellectual curiosity
 might pursue the situation further, but my advice to you is to ignore the
 "error" message until you are, in point of fact, confronted with an error.
  
  In short - don't worry about it.
  
  Hope this helps,
  
  - James Turner
    turnerj@cpva.saic.com

BTW - I would have responded by email but the SMTP mailer choked on your
address
From: jrd@cc.usu.edu
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: PKTMUX issues
Date: 6 Apr 92 14:12:37 MDT
Organization: Utah State University

In article <1992Apr6.040209.4827@watserv1.waterloo.edu>, eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
> jrd@cc.usu.edu writes:
>>	The ultimate solution to running multiple TCP/IP (generic terminology)
>>stacks in parallel over the same board is:
>>
>>	put a double ended TCP/IP stack between the board and all of the apps.
>>
>>On the bottom that constitutes one stack talking to the Packet Driver/NDIS/ODI
>>multiplexer. On the top packets are rebuild from the incoming ones, port
>>numbers are reassigned, checksums fixed etc and then the rebuilt packets are
>>sent up to the application as if brand new. Outgoing pkts get the same
>>treatment of "re-porting and re-sequencing." This is something like a gateway.
> 
> PKTMUX does this when necessary, but only then.  And doing so can be a
> cause for software failure. 
> 
> There are problems because some protocols first allocate
> a port and then send that port number over an existing connection to
> say, "hey, use this port".  Examples of this include FTP and BSD
> originated stuff such as TALK.  None of these protocols will work if you
> start tamperring with the protocols.
> 
> 
> Erick
> -- 
> Erick Engelke					  Engineering Computing
> 						 University of Waterloo
> Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
------------------
	A double ended TCP/IP stack has no problem with this because it
does a full decode on all incoming material and recodes it for sending. It's
a pseudo host servicing many clients and many exterior hosts. It just happens
to communicate using TCP/IP to clients because that's what they speak. The
problem to be solved is allocation and collision avoidance of ports and
sequence numbers and the like, and the only way of achieving that is to 
maintain the information in one spot. Per client translations occur between
them and the exterior world, in a fashion compatible with normal TCP/IP
usage and well known ports etc. A full decode is necessary to *understand*
what's being said and translate accordingly; incrementing a few numbers is
not the same thing. It's a software DELNI ("an Ethernet in a box"), an
Internet in a program. Hmmm, "Pseudo Host Internet Program" for long.
        I'm not advocating this thing, but rather pointing to what I think
is the logical conclusion.
	Joe D.
From: glazer@ohstpy.mps.ohio-state.edu (Jon Glazer)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: WINQVT/NET still UAEs with 3.1 (UAs)
Date: 13 Apr 92 19:46:59 GMT

Well I installed 3.1 of Windows hoping (beyond hope) that it would actually
make WINQVT/NET work reliably.  No dice!  I still get "Application Errors"
something on the order of "general protection fault in application."

Has anyone actually managed to get WINQVT/NET to work.  I am running the latest
ODI drivers with ODIPKT (still had the problems prior to this).

Is the fact that WINQVT always asks "OK to release old packet handles"
relevent?  Is there a way to stop it?

HELP PLEASE!
From: jim@CAI.LSUC.ON.CA (Jim Mercer)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: AHHK! Wattcp and Cutcp questions
Date: 15 Apr 92 20:59:58 GMT
Distribution: world
Organization: The Internet

> Ka9q so far seems to be the best package... I like how the Telnet,
> FTP (multiple sessions), Ping.. etc are integrated... BUT, its
> terminal emulation is absolutely horrid.. and unuseable by myself.

i believe the solution is to recompile it so that it uses bios calls,
and install ansi.sys in your config.sys

> Cutcp has a nice terminal emulation... but I can't start a direct
> FTP session without running ftpbin.exe and its security is non
> existant.. once a user is in, there IN.

why not ftp the file to you unix account, then ftp from your unix account
to your PC?

usually, you would go hunting on the internet, snarf some thing from here,
somethign from there, etc.

then once you have collected all you want, batch it all up via ftp into your
PC.

-- 
[ Jim Mercer  jim@lsuc.On.Ca  || ...!uunet!uunet.ca!lsuc!jim  +1 416 947-5258 ]
[ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA  ]
[ Standards are great. They give non-conformists something to not conform to. ]
[      The opinions expressed here may or may not be those of my employer     ]
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Subject: Re: Packet driver question
Organization: University of Waterloo
Date: Wed, 8 Apr 1992 20:57:43 GMT

 PPH93@DMSWWU1A.BITNET (Thomas Heller) writes:
>Is it safe to call send_pkt() from the (second) upcall to the receiver()
>function?
>
>I tried this once and it worked, but pkttrace became confused.

The packet driver is such a nice hardware independant interface that it is entirely
too easy to forget how restrictive your program should be.  The problem is that
packet drivers must deal with hardware interrupts and unspeakable hardware complexities
which differ from card to card.  So while the packet driver hides you from having to
program the dma controller or manage the interrupt system, you still must abide by
the limitations within which the packet driver must work.

What are those limitations?  Here is a short list off the top of my head, but by
no means is it complete.

Inside a packet driver upcall,...
1. No transmits - some cards would require interrupts to transmit and we are already
   (possibly) inside an interrupt so the transmit interrupt might be ignored and have
   entirely unpredictable results.
2. Don't use much stack space - could be inside DOS's tiny stack
3. Don't touch anything which waits for an interrupt - if you plan to be brilliant,
   learn all about interrupt priorities first and then come to grips with the fact
   that a packet driver could have any level from 0 to 15 or it might possibly be
   coming from an NMI source.
4. Expect transmit failures and reschedule output
5. Expect unreasonably large packets coming in and learn to say NO THANKS (pronounced
   0000:0000 )
6. Some packet drivers may disable interrupts, some may enable them.  I say don't mess
   with the interrupt state, the packet driver author may need it kept that way
7. Don't play with any hardware 
8. Don't touch the interrupt controller, don't even think of sending an EOI
9. Don't do any real processing, some packet drivers temporarily leave the card in a weird
   state for the duration of the upcall because they expect you will only execute a dozen
   or so instructions.

I suggest that you take the approach of SIMPLEST is BEST.  Merely buffer the packet and
process it later by implementing one of:
1. Polling - just poll for packets constantly
2. Poll on some regular interval - eg. tye to clock tick
3. Poll after a network card interrupt by chaining to the network card's ISR.  I don't 
   recommend this, but it is better than some other options.

The less hardware critical you make your program the more likely it is to work on a large
number of computers.  My TELNETD manages to work under almost every conceivable condition
simply because it follows those rules and only chains to one interrupt, the system timer
tick.

Erick
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
From: prao@ucsb.edu (Parik Rao)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: WinQVTnet & 3.1 No Worky!
Date: 7 Apr 92 19:12:26 GMT
Reply-To: prao@bluemoon.ucsb.edu
Organization: U.C. Santa Barbara

I don't use WinQVT much bit it worked for me.  Have you loaded WINPKT?

--
parik rao				                 prao@bluemoon.ucsb.edu