home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / ibmpc / 7389 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  3.2 KB

  1. Xref: sparky comp.protocols.tcp-ip.ibmpc:7389 comp.sys.ibm.pc.misc:16586 comp.dcom.lans.ethernet:2956 comp.os.msdos.programmer:12025
  2. Path: sparky!uunet!pipex!warwick!doc.ic.ac.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
  3. From: pcg@aber.ac.uk (Piercarlo Grandi)
  4. Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.misc,comp.dcom.lans.ethernet,comp.os.msdos.programmer
  5. Subject: BOOTP, pkt drivers, and ethernet board type
  6. Message-ID: <PCG.93Jan12184450@decb.aber.ac.uk>
  7. Date: 12 Jan 93 18:44:50 GMT
  8. Sender: news@aber.ac.uk (USENET news service)
  9. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  10. Organization: Prifysgol Cymru, Aberystwyth
  11. Lines: 63
  12. Nntp-Posting-Host: decb.aber.ac.uk
  13.  
  14.  
  15. Suppose you had hundred of PCs running MSDOS attached to a various
  16. number of Ethernets, by way of a dozen different types of cards (ISOLAN,
  17. WD, 3COM, ...).
  18.  
  19. Managing all these one by one would be terrible; it would be much nicer
  20. if you had a RARP/BOOTP/TFTP server with a centralized list of all
  21. machines (IP addresses,FQDNs, and so on).
  22.  
  23. It would be wonderful if the root partition (C:) on all these PCs were
  24. *absolutely identical* on all those PCs, so that it could be installed
  25. and made read only without hassle.
  26.  
  27. The problem is those dozen or so types of cards. In order to start the
  28. whole process the right driver (and its configuration) must be
  29. individuated (once this is done, everything becomes easy; we get the
  30. ethernet card address, we use that as key for a broadcast, and some
  31. RARP/BOOTP server notices it and then tells us everything we need to
  32. know).
  33.  
  34. I have thought about three possible solutions:
  35.  
  36.     1) Have some program that probes around and determines
  37.        the type of network card installed in the machine.
  38.  
  39. This looks rather a formidable task, so probably it is more sensible
  40. to consider:
  41.  
  42.     2) Use 4-6 spare bits in the CMOS configuration bytes to
  43.        record the network card type, just as there are two
  44.        fields for the drive type.
  45.  
  46.     3) Use some spare byte in the hard disk VTOC (all those
  47.        machines have an hard disk) to record the network card
  48.        type, just as there are fields to record partition types;
  49.        this could be done creating a fake partition, whose numeric
  50.        type were the card type, just using normal fdisk.
  51.  
  52. In other words I'd rather like two new DOS commands, 'nifset <number>'
  53. to record somewhere safe the type of the card in a machine, and
  54. 'niftype' that returns the same <number> in the 'errorlevel'.
  55.  
  56. I'd like to know if anybody has already thought along the same lines,
  57. and has already done something like this, and I welcome anybody's
  58. comments and suggestions on how to do this; in particular about:
  59.  
  60.     1) probing to determine the card type is feasible and how.
  61.  
  62.     2) which bits in the CMOS may be assumed to be usable.
  63.  
  64.     3) which bytes in the VTOC may be assumed to be usable.
  65.  
  66.     4) if any utilities like nifset and niftype already exists.
  67.  
  68.     5) once the nif type if obtained, how to configure LAN manager
  69.        (for packet drivers it's easy) for that device, *without
  70.        altering any file*.
  71.  
  72. Thanks in advance!
  73. --
  74. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  75.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  76.   alle orecchie del suo divino protettore, il dio della barzelletta
  77.