daved@usperb.Dayton.NCR.COM (Dave Dresselhouse) (07/11/90)
I'm trying to get Novell Netware v2.15, and FTP's PC/TCP to coexist on the
same PC using the following components:
NE1000 packet driver (from Clarkson)
PC/TCP Kernel (Generic Ethernet - from FTP)
IPX.COM generated via BYU Packet Driver modules
(Note: all of these components came on the distribution
diskettes from FTP when the Generic Ethernet
PC/TCP kernel was purchased).
The documentation for the BYU software states that the Netware Server OS
must be modified so that it looks at "Novell 8137" format packets instead
of IEEE 802.3 packets. This appears to be easily accomplished through the
use of the "econfig" program supplied. The documentation also says that if
you don't modify the Server, you will get the standard "CAN'T LOCATE FILE
SERVER" message when invoking the workstation shell (NET3).
My problem/question is this:
I've not yet modified the Server to look at the 8137 format packets,
but when I invoke NET3 on the workstation after loading the Packet Driver,
PC/TCP and the new IPX, the PC just hangs. No "Can't connect" message.
If I modify the Server to look at 8137 packets, and the new IPX/NET3
combination still doesn't work, will I be able to connect to the Server
from an 802.3 workstation and reset it to look at 802.3 again? (I have
this fear that once I modify the server for 8137 and the new workstation
software doesn't work, I'll be locked out of the server with no way
to put it back the way it was).
Has anyone been successful with this?
Any help would be greatly appreciated!
-Dave
-------------------------------------------------------------------------
Dave Dresselhouse dave.dresselhouse@Dayton.NCR.COM
NCR Corporation (513) 445-4449
U. S. Group Dayton, OH
-------------------------------------------------------------------------keith@excelan.COM (Keith Brown) (07/12/90)
In article <475@usperb.Dayton.NCR.COM> daved@usperb.Dayton.NCR.COM (Dave Dresselhouse) writes: > >My problem/question is this: > I've not yet modified the Server to look at the 8137 format packets, > but when I invoke NET3 on the workstation after loading the Packet Driver, > PC/TCP and the new IPX, the PC just hangs. No "Can't connect" message. Well, NET3 takes a little time to give up hope of finding a file server but it should return the machine to you eventually. Before loading IPX/NET3, make sure PCTCP is working. That will tell you if you've loaded the PD up correctly for your board configuration. > > If I modify the Server to look at 8137 packets, and the new IPX/NET3 > combination still doesn't work, will I be able to connect to the Server > from an 802.3 workstation and reset it to look at 802.3 again? No. But read on..... > (I have > this fear that once I modify the server for 8137 and the new workstation > software doesn't work, I'll be locked out of the server with no way > to put it back the way it was). Never fear. All is redeemable! At least it should be. I'm assuming that you've been using an IPX.COM that has been linked to go straight to your ethernet hardware until now. This IPX.COM is likely to be "econfig"able (check, some aren't! If this is an NE1000 and you've been using an IPX.COM linked with our driver though, it is!) so if you econfig your server and the PD shell doesn't work at the workstation, you can revert to your old IPX.COM in an "econfig"d incarnation to connect to your server and set things back the way they were. Assuming your server has a single ethernet card installed, configured as LAN A, log into it from a DOS workstation as supervisor and do something like this: F:\SYSTEM> copy net$os.exe net$os.old - Better safe than sorry! F:\SYSTEM> econfig net$os.exe a:e 8137 Reboot the server and try your PD IPX.COM and NET3 at a workstation. If it all goes horribly wrong, take your old, straight to the metal IPX.COM and: C:\BIN> copy IPX.COM IPXETH.COM C:\BIN> econfig IPXETH.COM shell:e 8137 <- *CHECK THIS WORKS FIRST (BEFORE MESSING WITH YOUR SERVER)* C:\BIN> IPXETH C:\BIN> NET3 <login in as supervisor and either> F:\SYSTEM> copy net$os.old net$os.exe <or> F:\SYSTEM> econfig net$os.exe a:n <and reboot> Remember to revert to the non econfig'd IPX.COM at the workstation too! > >Has anyone been successful with this? Yes. Me... I thought this was worth posting as "econfig" has a tendancy to confuse folk and this might kill a few birds with one stone with regards to it's usage. Keith ---------------------------------------------------------------------------- Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 San Jose, California 95131 Net: keith@novell.COM ----------------------------------------------------------------------------
fks@VAX.FTP.COM (Frances Selkirk) (07/13/90)
You could try putting two cards in the server, temporarily, and econfig- ing one of them to test against. If you are still having problems with the reconfigured server, write me at info@ftp.com. Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880
meggers@mothra.nts.uci.edu (Mark Eggers) (07/13/90)
A more reliable way to recover is to flag net$os.exe sharable, and copy it to a floppy (you do have a 3 1/2 on the server, I hope). Now econfig your server, and try out the packet driver IPX.COM. If it works, great. If it doesn't, and you can verify the correct operation of the packet driver with Clarkson's CUTCP, or PCIP, or KA9Q, then you can recover in the following manner: 1. Boot the server with DOS 2. Put in your backup copy of net$os.exe 3. Start up the server 4. Mark net$os.exe sharable, and copy it to the server's hard disk 5. Mark net$os.exe nonsharable 6. Down the server 7. Remove the floppies, and reboot The biggest problem to watch out for with the packet drivers is high memory conflicts between various video boards (especially VGA and EGA) and on-board Ethernet card memory. Hope this helps - /mde/