[comp.protocols.tcp-ip.ibmpc] WIN TCP R4.1 w/packet driver

nestor@NMS.HLS.COM (Nestor Fesas) (10/31/90)

    I regularly see references to using WIN TCP w/PD - in fact,
    there is a file pktdrv.exe (or something like that) in the
    distribution.  What I do not see is anything in the
    documentation about how to do so. I tried the obvious (??)
    things like

    <deleted text>

	3) using another card (Hughes LAN Systems 4140)
	   and loading the driver S/W (MPD4140, MPDINIT)
	   which I am guessing creates a PD I/F since
	   PC/TCP works fine with both that combination
	   and with a packet driver, then trying 1)
	   and 2) again.

    No luck. Any help appreciated.

Your option #3 doesn't work because MPD4140 and MPDINIT do not constitute
a PD interface.  In addition,  we do not provide any direct support for
WIN TCP.  Unfortunately,  I can't provide you with a specific solution to
your problem because I'm not really familiar with WIN TCP's operational
details.  However,  I believe WIN TCP provides an NDIS interface.  Generally
speaking,  you could try using WIN TCP's NDIS interface along with 3 COM's
NDIS driver for the 3c505.  If memory serves,  the 3 COM NDIS driver is
called ELINKPL.DOS or something along those lines.  Depending on how old your
3 COM cards are,  the NDIS driver may not be on the drivers disk that
accompanied them.  In that case you'll need to contact your 3 COM rep.

Alternately you could try ProLINC,  a communications product we sell.
ProLINC offers 

	-	Full TCP support (e.g. telnet, ftp, smtp, etc.).
	-	Concurrent connections to LAT hosts.
	-	Concurrent connections to Novell, Banyan and NFS file
		servers.
	-	Interrupt 14H redirection.
	-	User configurable menu system.
	-	NDIS support.
	-	Support for the HLS 4140 Ethernet card and 6130 Broadband
		card.


Nestor.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
        Nestor A. Fesas, Jr.           =         Hughes LAN Systems
        nestor@hls.com                 =         1225 Charleston Road
                                       =         Mountain View, CA 94043
                                       =         415-966-7473
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

jbvb@FTP.COM ("James B. Van Bokkelen") (11/01/90)

            3) using another card (Hughes LAN Systems 4140)
               and loading the driver S/W (MPD4140, MPDINIT)
               which I am guessing creates a PD I/F since
               PC/TCP works fine with both that combination
               and with a packet driver...
    
    Your option #3 doesn't work because MPD4140 and MPDINIT do not constitute
    a PD interface. ....

I would say that if the Class 1 Packet Driver version of PC/TCP (ETHDRV.EXE)
runs on it, it is at least arguably a Class 1 packet driver.  I could
understand not wishing to support it except with your own product...

As to why the WIN/PC stuff might not work where PC/TCP does, there are a
number of potential causes, most historical (we encountered the driver
bugs long ago, and built in code to cope with them, where Leo may not
have heard of this one till the original post).  My first guess is that
the packet length passed in CX to the first receiver() upcall is wrong.
Does the TWG product have any keyboard commands to display low-level
errors like "too short" or "too long" or "unknown type"?

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

nestor@NMS.HLS.COM (Nestor Fesas) (11/01/90)

JBVB writes:

>     
>     Your option #3 doesn't work because MPD4140 and MPDINIT do not constitute
>     a PD interface. ....
> 
> I would say that if the Class 1 Packet Driver version of PC/TCP (ETHDRV.EXE)
> runs on it, it is at least arguably a Class 1 packet driver.  I could
> understand not wishing to support it except with your own product...
> 

Sorry,  James is right.  In my haste,  I mistated the facts.  I should have
said that MPD4140 and MPDINIT were not intended to function as general
Packet Driver interfaces and thus have not been tested in that capacity.

Nestor.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
        Nestor A. Fesas, Jr.           =         Hughes LAN Systems
        nestor@hls.com                 =         1225 Charleston Road
                                       =         Mountain View, CA 94043
                                       =         415-966-7473
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

BEEBE@yalemed.bitnet (Rick Beebe) (11/01/90)

>I regularly see references to using WIN TCP w/PD - in fact, there is a
>file pktdrv.exe (or something like that) in the distribution. What I
>do not see is anything in the documentation about how to do so. I
>tried the obvious (??) things like
> 
>1) loading the appropriate PD (3c505), then the WIN TCP kernel
> 
>2) loading the PD, then running pktdrv.exe, then the kernel
 
Basically #2 is right. Pktdrv.exe takes the place of the hardware specific 
driver. For example, instead of running 3c505 then the kernal, you run pktdrv 
then the kernal. In order for pktdrv to work, the packet driver must be loaded. 
I did have to play around with which interrupts were used. I'm sorry, but I 
don't remember now which one's I used. I _think_ I used 0x60 for the packet 
driver and 0x61 for pktdrv. (It took me a while to realize that I didn't want to
    
use the same interrupt for them both).
 
-----------------------------------------------------------------------------
                                Rick Beebe                    (203) 785-4566
 *****  *****  *****  *   *     Biomedical Computing Unit
   *      *    *      **  *     Yale University School of Medicine
   *      *    ***    * * *     333 Cedar Street, New Haven, CT 06514
   *      *    *      *  **
   *      *    *      *   *     BEEBE@YALEMED.BITNET
                                beebe%biomed.decnet@venus.ycc.yale.edu
-----------------------------------------------------------------------------
 

ljm@TWG.COM (11/08/90)

>Does the TWG product have any keyboard commands to display low-level
>errors like "too short" or "too long" or "unknown type"?
>

Sort of -- we allow the user to show all the MIB variables on his host.
Requests for buffer sizes < 0 or > max ethernet result in ifInDiscards.

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com