vogt@udecc.engr.udayton.edu (Staff- Tim J Vogt) (03/15/91)
In preparation for a large number of PC's that will soon be put on our
campus network (specifically in the School of Engineering), we have been
testing out Clarkson's WD8003E packet driver on a WD8003eb card with NCSA
Telnet v2.3b14. We have not been able to get NCSA to work properly with the
driver, although it works flawlessly with the regular wd8003e entry in
config.tel. Using trace and dump (as well as a network analyzer), we found
that the driver will send packets fine, but apparently is not receiving at all.
NCSA Telnet comes up with the error message: "Warning, packet driver
vector incorrect, using default search" when run. The config.tel entry we've
been using is:
hardware=packet
interrupt=0x60 ; (set with wd8003e.com as <int_no.>)
and we've tried other software interrupts, in case that was the problem.
We've also tried including various other items in the congif.tel (like the
ioaddr and mem. address of the card) with no further success.
It seems we've overlooked something (my guess is in the config.tel
entry), but have found very little info in any of the docs. Any and all help
would be greatly appreciated.
Please use email, as I very rarely have time to read news.
One more thing: Has anyone heard about packet drivers which will
respond to snmp queries from the net? That is a large reason we are looking at
using packet drivers rather than NCSA's built-in interface.
--
------------------------\ /-------------------------\ /------------------------
`Paradise is exactly like| -={Tim Vogt}=- |`Let us not go gently to
where you are right now |vogt@udecc.engr.udayton.edu| the endless winter night'
only much, much better.'| ________ | nelson@sun.soe.clarkson.edu (Russ Nelson) (03/19/91)
In article <1991Mar14.212817.4903@udecc.engr.udayton.edu> vogt@udecc.engr.udayton.edu (Staff- Tim J Vogt) writes:
Using trace and dump (as well as a network analyzer), we found that
the [packet] driver will send packets fine, but apparently is not
receiving at all.
When a packet driver will send but not receive packets, it is almost
always interrupt-related. Be sure of two things: 1) that you are
specifying the same interrupt that the hardware is using, and 2) that
there are no interrupt conflicts. Many Ethernet cards default to
interrupt 3, which is used by the second serial port.
NCSA Telnet comes up with the error message: "Warning, packet
driver vector incorrect, using default search" when run. The
config.tel entry we've been using is:
hardware=packet
interrupt=0x60 ; (set with wd8003e.com as <int_no.>)
and we've tried other software interrupts, in case that was the
problem. We've also tried including various other items in the
congif.tel (like the ioaddr and mem. address of the card) with no
further success.
When you use hardware=packet, comment out all hardware-related parameters,
such as interrupt=, membase=, etc. Telnet can determine them on its own.
One more thing: Has anyone heard about packet drivers which
will respond to snmp queries from the net? That is a large reason
we are looking at using packet drivers rather than NCSA's built-in
interface.
I know that Cabletron is doing something in that vein, but I know nothing
more than that.
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.trier@cwlim.INS.CWRU.Edu (Stephen C. Trier) (03/20/91)
In article <NELSON.91Mar19095405@sun.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: > One more thing: Has anyone heard about packet drivers which > will respond to snmp queries from the net? > >I know that Cabletron is doing something in that vein, but I know nothing >more than that. Cabletron has such beasts. Their version 1.03.00 and above packet drivers will interface with an SNMP TSR. Apparently, the TSR will intercept only SNMP packets and will pass all other IP traffic up to user applications, so you can still use TCP/IP software. (In other words, this is a special case, getting around the normal prohibition against multiple stacks of the same protocol.) The SNMP does not convey much information. A configuration file must be provided, and the SNMP implementation will use the information within it for its IP address, location, machine name, and a few other options. As far as I know, protocol statistics can not be retrieved. The only useful task we found for the SNMP TSR was to respond to the automatic discovery feature in network management software. It was decided that this was not worth requiring every user to give up > 20K of RAM. In addition, the configuration file was awkward, since all of our configuration information is downloaded dynamically via BOOTP. Therefore, we are not using SNMP. I believe that an SNMP implementation would be more useful inside a TCP/IP kernel, where useful statistics can be gathered and BOOTP information can be easily retrieved. -- Stephen Trier Case Western Reserve University Work: trier@cwlim.ins.cwru.edu Information Network Services Home: sct@seldon.clv.oh.us %% Any opinions above are my own. %%
fks@FTP.COM (Frances Selkirk) (03/22/91)
Our TCP/IP package, PC/TCP, does contain an SNMP agent, and I believe the new PC-NFS release for Sun does as well. TCP/IP with SNMP does exist, and is getting a lot easier to find! (I may even be missing a vendor or two...) Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880