Frequently asked Questions/Answers on Solaris 2.x networking:

• What is NIS+?

• What are the key differences between NIS and NIS+?

• What are the benefits of NIS+?

• Can all YP/NIS commands still be used?
  

• Can I revert back to using NIS?
  

• Can I still send/receive mail outside my domain?
  

• Can I do lookups in other domains
  

• Can I log in on machines in other domains?
  

• Can NIS+ be run on a machine running 4.x?
  

• Will conversion to NIS+ cause performance problems?
  

• What are the known major problems with NIS+?
  

• What is involved in setting up NIS+ on a desktop?
  

• Why do I have to have several passwds?  NIS did not require one.
  

• Can two different passwds be used for NIS+ and logging in?  Is there
  any impact if I have my own entry in my local /etc/passwd file?
  

• The machine name collides with someone's login name.  How can this
  be fixed?  Why doesn't it work now, when it worked before?
  

• Is it still possible to access an NIS+ domain and yet use an NIS
  domain (different from NIS+ domain) for daily operations?
  
  Installation of Admintool and Host Manager
  
  

• What does the choice of name service in Host Manager and
  User Account Manager mean?
  
  

• If name service should always be the same, why do Host
  Manager and User Account Manager present a choice?
  
  

• Can I select a different name service for each host when
  adding clients through Host Manager?
  
  

• Are there exceptions to the rule that all Solaris hosts on
  a network should use the same name service(s)?
  
  

• Does saying that all Solaris hosts should use the same
  name service(s) mean they should use only one name service?
  
  

• /etc/nsswitch.conf appears to provide a great deal of
  flexibility, some of which isn't used.  What's the file for?
   
  

• Why is the None name service option provided?
  
  

• If I explicitly specify a different name service when
  adding a client, will Host Manager "make it right"?  For
  example, if my network is running NIS+, yet before adding a
  new dataless client I specify None, will Host Manager update
  all the right files in the right way to make the new client
  known all across the NIS+ domain?
  
  

• How do the admintool tools support NIS?
  
  

• The message Host Manager gives when I select NIS and try
  to do an operation that might involve updating maps seems to
  imply the lack of support for NIS updates has something to do
  with mixed OS versions, and might change in the future.  Is
  this true?
  
  

• Why can't the admintool tools update NIS automatically?
   
  

• What does it mean to say a printer is a NIS+ Printer?
   
  IP Interface
  
  

• Is there documentation that describes the interface
  between IP and network drivers, namely, the SUN specific
  requirements not outlined in the DLPI Version 2
  specification?
  
  

• When an ifconfig device0 plumb is issued, the driver
  immediately receives a DL_INFO_REQ. Exactly what is required
  in the DL_INFO_ACK from a Style 2 provider?
   
  

• Is it possible for the driver to be a CLONE driver and
  also a DLPI Style 2 provider?
  
  

• If so, how do I map the minor number selected in the open
  routine to an instance prior to a DL_ATTACH_REQ? The
  technique of using the  minor number to obtain the instance
  in the getinfo routine is not  valid prior to the
  DL_ATTACH_REQ. How do you suggest this be handled?
  
  

• In the examples a minor node is created each time the
  driver's attach routine is called. How would a CLONE driver
  attach to multiple  boards, that is, have multiple instances,
  and still only create one  minor node?
  
  

• Does Solaris 2.1 TCP/IP support Streams???
  
  

• Does SunOS 4.x TCP/IP support Streams??
   
  

• Does Solaris 2.1 ethernet drivers support LLI 2.0
  interfaces???
  
  

• Does Solaris 2.1 DLPI provide  both connection oriented
  services and connection less services. Also, is your DLPI
  Version 2.0, which includes multicast facilities.
  
  

• Is multicasting supported on SunOS 4.x? If not, how can
  the customer obtain this feature?
  
  Question on RPC and TLI
  
  

• We are using the TLI functions such as t_open and t_bind
  in one of our programs.  When we do a t_bind call, why do we
  get an M_DATA ioctl  rather than an M_PROTO?  Do you intend
  to do this permanently?
  
  

• I'm looking for RPC development kit for Macintosh.
  Can you help?
  
  

• Does Solaris 2.1 support XTI or TLI interfaces?
  
  

• Does SunOS 4.1 support XTI or TLI interfaces?
  
  NFS Interoperation
  
  

• With Solaris 2.x configured as a client, nfs mount with
  with HP-UX or AIX machines will not work, even though
  dfshares shows that the file systems are exported.The error
  message "Server not responding" appears.
  
  
  * What is NIS+?
  
      Network Information Service (NIS+) is an enterprise level 
      naming service designed to serve small to very large 
      networks.  It is a replacement for earlier NIS (nee YP) and a 
      complete rewrite. In NIS compatibility mode, NIS+ serves NIS 
      client requests as well.
  
  
  
   * What are the key differences between NIS and NIS+?
  
      There are many differences, but the main four are:
  
         - NIS had a flat name space, while NIS+ is hierarchical.
           With NIS+, growth and changes can be easily managed.
  
         - NIS+ is secure and allows fine grain access control.
  
         - NIS+ updates are on incremental basis and much faster (in 
           minutes).
  
         - NIS tables were single key-value pairs while NIS+ has 
           multiple key value pairs.  This means that you can do 
           searches based upon a particular value of a particular key.
  
   * What are the benefits of NIS+?
  
      Getting maps propagated no longer requires waiting 24 hours or
      more.  NIS+ does fast incremental updates.  So, it should 
      be very fast and easy to update these changes.
  
      It is much easier to traverse through all domains.  With NIS, there
      was no easy way to find out information about other domains.
  
      There is improved fault tolerance even if some of the 
      NIS+ servers fail.  The client will attempt to bind to any of 
      the NIS+ servers even if they are not the same subnet.
  
      The local sysadmin can set policies to allow users to change
      some of the fields of their entries.  For example, a user could 
      change the shell or home directory without going through a sysadmin.
  
  * Can all YP/NIS commands still be used?
  
      This will depend upon whether there is a NIS server 
      available for the domain OR whether the NIS+ server is 
      running in YP compat mode.  If it is, then all of the YP
      commands should be usable, except those commands that 
      change the NIS maps such as yppasswd or chkey for publickey 
      information.
  
      Even if the NIS and NIS+ domainnames are not the same, ypset 
      can be run and bound to a different domain than its own 
      local domain.
  
      There will be some differences in terms of the names of the
      automounter maps.  These maps no longer contain embedded dots.
      Also, some of the maps, such as the hosts map, may now look different.
      If some of the applications use NIS API and refer to maps with
      embedded dots in them, then they will not be able to find those maps.
  
      It is recommended that NIS+ commands be used for queries.
  
  * Can I revert back to using NIS?
  
      That depends upon the way things were set up.  If there is 
      still a NIS server on the subnet, it can still be done.  The 
      main changes required will be:
  
   	- change the domainname back to what it was
     	- change the /etc/nsswitch.conf to the earlier set up
  
  * Can I still send/receive mail outside my domain?  Is my 
    NIS+ domain same as my mail domain?
  
      Yes, you should be able to send/receive mail as earlier.  
      For mail purposes, you are still a part of the domain above 
      you.  For example, if you are currently in XYZ.Eng.Sun.COM, 
      for mail purposes, you are in Eng.Sun.COM domain.  Your email 
      address may change depending upon the new NIS+ domainnames.
  
  * Can I do lookups in other domains?
  
      Yes, just specify the complete NIS+ name of the table/entity
      to be located.
  
  * Can I log in on machines in other domains?
  
      Only if your local credentials have been added to that other domain.
  
  * Can NIS+ be run on a machine running 4.x?
  
      No, not as a client.  Only 4.X NIS+ servers are supported.
      There is no support for any of the name service switch
      and the associated getxxbyyy routines in libc.  However, from 
      a NIS+ 4.X server, all NIS+ commands can be executed.
  
  * Will conversion to NIS+ cause performance problems?
  
      In normal operations, there should not be any impact.  A 
      few things are substantially faster; for example, doing 
      su with NIS+ has become very fast.
  
      There may be an increase in the number of packets that go to
      the network.  We hope to address that in the 493 release.
  
  * What are the known major problems with NIS+?
  
      NIS+ servers (when running in NIS compatibility mode) can 
      serve NIS requests from 4.X clients but it cannot forward 4.X 
      DNS requests to the nameserver.  This means that one cannot 
      talk to other DNS domains.  This is not a problem with Solaris 
      2.0 clients which use the name service switch to get the 
      appropriate access.
  
      The installation isn't exactly fool-proof.  This will be addressed 
      in a future release. 
  
  * What is involved in setting up NIS+ on a desktop?
  
      Solaris 2.0 or higher is required to be able to run NIS+.
      Make the following changes:
  
  	- Change the domainname to the new NIS+ domainname.
  	- Create /var/nis directory.
  	- Add the IP address for the NIS+ server to the /etc/hosts file.
  	- Change the /etc/nsswitch.conf file to use NIS+ instead of NIS.
  	- Add /etc/resolv.conf file along with nameserver entries
  	- Change the /etc/auto files to refer to automounter
  	    maps in auto_form from auto.form.
          - Add NIS+ credentials in the cred table for yourself as 
    	    well as for your machine.
  
  * Why do I have to have several passwds?  NIS did not require one.
  
      NIS+ is secure; i.e., before giving you any information, the
      NIS+ server verifies that you do have the rights to access that
      information.  This security is based upon secure RPC, which needs
      you to have publickey and secretkey stored with NIS+; and your
      secretkey is encrypted with your passwd.  Hence, you need this
      extra passwd during chkey time.  If this passwd is not the same
      as your login passwd, then you will not be able to make NIS+
      calls unless you have done an explicit keylogin(1).
  
      NIS was not based upon secure RPC, so there was no need for
      a passwd.  You still needed a passwd for logging in, just as
      in the old time-sharing days.
  
  * Can two different passwds be used for NIS+ and logging in?  Is there 
    any impact if I have my own entry in my local /etc/passwd file?
  
      Yes, you can have separate passwords, but this means that you
      you will have to do a keylogin(1) before you can make any NIS+
      operations.  So it is not recommended. 
  
      It is reasonable to have the passwd entry also in the
      /etc/passwd file; just make sure that it is the same as in passwd table.  
      The only problem occurs when you change your keys.  During the 
      installation time, you would normally do a chkey, and chkey,
      being a user level program, cannot read your /etc/shadow file.  
      As a workaround, set the passwd entry in /etc/nsswitch.conf to
      nisplus and files, do the chkey and then put it back the original way.
      You will also have to change your passwds at two places, once in your
      local passwd file and then in the NIS+ passwd table with passwd(1) and 
      nispasswd(1), respectively.
  
  * The machine name collides with someone's login name.  How can this
    be fixed?  Why doesn't it work now, when it worked before?
  
      Clients of NIS+ (called as NIS+ principals) can be both 
      machines as well as normal users.  The NIS+ principals are 
      named as use_login.domainname or machinename.domainname.  For 
      example, if a user's NIS+ principal name is name.eng.sun.com, and
      the machine's NIS+ principal name is machine.eng.sun.com,
      NIS+ does not distinguish between the two - both of them have
      their own associated credentials and NIS+ access control 
      mechanism uses it to allow/deny permission to access information.
  
      The machines and users now share the same name space.  In 
      the past, this was not a problem because anyone could be a 
      client of NIS and access NIS information.
  
      Approximately 10% of users may find this collision.  In such cases,
      preference is being given to the user; i.e., the user gets 
      to keep the same name and the machine's name has to be changed.
      Choose a new name for the machine and add an alias for the
      machine's old name. 
  
  * Is it still possible to access an NIS+ domain and yet use an NIS
    domain (different from NIS+ domain) for daily operations?
  
      It is possible but the steps are slightly complicated. The 
      problem comes from the fact that the domain names are 
      different and that all entries in /etc/nsswitch.conf assume 
      that they are all to be resolved to the current domainname.  
  
      This is the workaround:
  
      1. # domainname newNIS+domain
      2. Edit the /etc/nsswitch.conf file so it contains only files for
         publickey.  Comment out the entry for "nobody" in the
         /etc/publickey file.
      3. Kill ypbind.
      4. Add the IP address of the NIS+ server in /etc/hosts file.
      5. # nisinit -c -H server_name
      6. # nis_cachemgr
      7. Test it by doing nisls or any other NIS+ operation on
         the NIS+ domainname
      8. # domainname old_domain_name
      9. Restart the ypbind
  
      With this workaround, you are now accessing NIS+ tables as "nobody"
      and you will have to specify the complete directory name for
      any operation.  Also, you can no longer make any secure RPC call.
  
  
  * I recently installed a 486/50 machine as an NIS client in 
    house and connected to the local network via a THICK net 
    Ethernet drop. That machine is now up at a vendor site 
    who has THIN ethernet and is not running NIS+ nor NIS, so
    NONE was specified during the configuration.  This is a class B 
    address, i.e., 130.35.19.70 and the subnet mask is ffff0000. 
    However, there are two problems:
  
    1. Cannot talk to any other machines 
    2. OPENWINHOME hangs consistently
   
      When using THIN net, make sure the smc card is reconfigured
      for THIN net; the default is usually THICK net.  
  
      If no error messages are being returned from the smc driver 
      during boot up, then the IRQ and I/O address should be correct.
      However, there might be a conflict of the shared memory address
      and usually this is with the disk controller.
  
  * A user is trying to use NIS+ on a PC running Solaris 86.
    There is an SS2 set up as the NIS+ master server.  NISD
    is running with a security level of 0.  The directions in
    in the answerbook were followed for setting up an NIS+ client.
    An account was created called markl on a Sparc2 (the NIS server).
    The home directory is in /home2/markl, and the automounter is being
    used to provide a home path of /home/markl.
  
    Markl can log onto the Sparc2 without problems.  When attempting to
    login as markl on Solaris86 (the Intel box), the system responds that
    markl doesn't have a password so one should be made.  It runs the
    passwd command (the word "passwd" is on the screen) and then there
    is no markl account.  Then back to login.  When markl logs in to root,
    and does csh, he can su markl, cd ~markl, niscat passwd.orig_dir and
    see the passwd data.  It has an entry for markl.  If he does su to junk,
    he's told the junk is not a valid account.  It seems that the NIS
    bindings are working, just not login.
  
    Also, markl can go to a system running SunOs 4.1.2 as an NIS 
    client (not NIS+) and login as markl.
   
    Has anyone tested the NIS+ client with a Sparc based NIS+ 
    master server. Anyone have any ideas on what wrong?
  
      The following is the workaround for this problem:
  
      Apparently this problem is caused by the passwd file, which is used 
      to populate the passwd table by using the nisaddent "passwd" 
      command.  It assumes that the file is a 5.X passwd file and 
      hence does not populate the "shadow" column of the passwd table.
      The sysadmin is then supposed to run the nisaddent 
      command with the equivalent shadow file.
  
      For example:
  
  	#  cat /etc/passwd | nisaddent -v passwd
   	#  cat /etc/shadow | nisaddent -v shadow
  
      However, in this particular case, there was no equivalent 
      shadow file available so the passwd col was empty, and no one
      could login to these machines.
  
      Workaround #1:
  
      The workaround is as follows:
  
      The /etc/passwd file needs to contain the encrypted password.
  
    	#  cat /etc/passwd | nisaddent -v passwd
   	#  awk -F: '{printf("%s:%s:6445::::::\n", $1, $2)}' 
          /etc/passwd > /tmp/shadow
          #  cat /tmp/shadow | nisaddent -v shadow
  
      Workaround #2:
  
      The other way to solve this problem is to use the -y option 
      of nisaddent. This only works if there is a running 
      YP domain set up. First ypxfr the passwd map to the machine 
      and then use nisadent -y:
  
   	#  /usr/lib/netsvc/yp/ypxfr -c -d YP_DOMAINNAME -h YP_SERVER 
  	passwd.byname
   	#  /usr/lib/nis/nisaddent -y YP_DOMAINNAME passwd
  
      With this way, there is no need to run any awk script and 
      everything works fine.
  
  * The NIS+ server was unavailable and the clients were not
    allowing logins.
  
      Change the following two lines in the nsswitch.conf file:
  
          passwd:     files nisplus
          group:      files nisplus
  
      to: 
  
          passwd:     files [NOTFOUND=return] nisplus
          group:      files [NOTFOUND=return] nisplus
  
  
  * What is the significance of having the default entry as
    networks: nis [NOTFOUND=return] files in /etc/nsswitch.conf?
  
      The reason that the default nsswitch.conf file contains 
      "[NOTFOUND=return]" is to allow the default behavior
      to be 4.x-compatible, and 4.x generally follows a policy of 
      "only look at 'files' if 'nis' is unavailable".  Thus, entries 
      like
  
          networks:   nis [NOTFOUND=return] files
  
      do the right thing for 4.x-compatibility 
  
  
  _____________________________________________________________
  
  
  Installation of Admintool and Host Manager
  
  Frequently asked Questions/Answers on Solaris 2.x,
  in the area of networks
  
  
  * What does the choice of name service in Host Manager and 
    User Account Manager mean?
  
    The choice of NIS+, NIS, or None is typically per-network.  
  Usually you should specify it the same way every time you 
  start Host Manager or User Account Manager on a network.  Do 
  not change name services per-host or per-user.  If you need 
  to edit a particular record in a particular database stored 
  by a particular name service, you can use the lower level 
  tool Database Manager.
  
  
  Q) If name service should always be the same, why do Host 
  Manager and User Account Manager present a choice?
  
  A) Firstly, admintool can't always figure out what the right 
  answer is and so is asking you for verification.  And 
  secondly, sysadmins with unusual configurations sometimes 
  need to override the choice of name service.
  
  
  Q) Can I select a different name service for each host when 
  adding clients through Host Manager?
  
  A) The simplest answer is "No".  All centrally administered 
  Solaris hosts on a network should use the same name 
  service(s).  Even though Solaris provides another name 
  service (NIS+), a new set of administration tools 
  (admintool), and the ability to control the order of name 
  service lookups by database (/etc/nsswitch.conf), it still 
  expects all centrally administered hosts on the network to 
  use the same name service(s).
  
  Unfortunately the appearance of the admintool tools has 
  misled some users to conclude that use of different name 
  service(s) by different Solaris hosts was intended to be 
  fully automatic and transparent.
  
  
  Q) Are there exceptions to the rule that all Solaris hosts on 
  a network should use the same name service(s)?
  
  A) Yes.  Some support is provided to ease transition from NIS 
  to NIS+, or from None to NIS+.  Knowledgeable users can use 
  the None option to set up some test configurations.  And 
  power users may wish to modify the /etc/nsswitch.conf file on 
  their workstation.
  
  
  Q) Does saying that all Solaris hosts should use the same 
  name service(s) mean they should use only one name service?
  
  A) No.  Hosts normally use a combination of local and network 
  name services to allow both independent bootup and easy 
  normal operation, and to provide local overrides to network-
  wide information.  For example the template 
  /etc/nsswitch.nisplus allows local entries for passwd, group, 
  automount, and aliases to override network-wide information.
  
  
  Q) /etc/nsswitch.conf appears to provide a great deal of 
  flexibility, some of which isn't used.  What's the file for?
  
  A) The initial motivation for /etc/nsswitch.conf was to give 
  users full control over where and in what order 
  gethostbyname() looked, similar to Ultrix.  The 
  implementation scheme used was so simple and powerful that 
  its use was extended to cover most name service lookups 
  rather than just gethostbyname() calls.  This increased
  flexibility is available to all users.
  
  As distributed, Solaris uses one of only three standard 
  configurations of /etc/nsswitch.conf (templates 
  nsswitch.nisplus, nsswitch.nis, and nsswitch.files), 
  depending on whether the network name service is NIS+, NIS, 
  or None.  A simple change to activate DNS for gethostbyname() 
  calls is included in the comments inside 
  /etc/nsswitch.nisplus.
  
  
  Q) Why is the None name service option provided?
  
  A) The primary reason for the None name service option is to 
  support customers who won't run either NIS or NIS+.  Most 
  such customers keep a master copy of /etc configuration files 
  on a central machine and use `rdist` or a similar tool to 
  broadcast copies to all workstations.
  
  The second reason for the None name service option is to 
  support local overrides to network-wide information.
  
  The third reason for the None name service option is to help 
  work around the lack of programmatic updates to NIS.
  
  Finally, the None name service option supports quick setup of 
  demo or test configurations by knowledgeable users who either 
  can't or don't want to update the name service.
  
  
  Q) If I explicitly specify a different name service when 
  adding a client, will Host Manager "make it right"?  For 
  example, if my network is running NIS+, yet before adding a 
  new dataless client I specify None, will Host Manager update 
  all the right files in the right way to make the new client 
  known all across the NIS+ domain?
  
  A) No.
  
  There is no combination of file and name service updates that 
  will make all such mixed configurations work right.  No 
  matter how hard Host Manager tried, some combinations would 
  never work.  Non-support of different kinds of name service 
  clients on the same network shows up throughout Solaris; it's 
  not just a restriction imposed by the admintool tools.
  
  
  Q) How do the admintool tools support NIS?
  
  A) All NIS maps can be read by all admintool tools.
  
  No NIS map can be programmatically updated by any admintool 
  tool. Users of any admintool tool on a network using NIS must 
  perform a manual procedure.  That procedure involves 
  pretending to use None name service, capturing the changes in 
  /etc files, manually merging the changes into the NIS master 
  files and remaking the NIS maps, and cleaning up the /etc 
  files.  The new information will not be known across the 
  entire NIS domain until all the push operations initiated
  during the manual procedure have completed.
  
  Note that neither this use of the None name service option as 
  part of the manual workaround procedure, nor the on-screen 
  documentation of this manual procedure by some admintool 
  tools, change the fact that admintool tools do not expect 
  different Solaris hosts on the same network to use different 
  name service(s).
  
  
  Q) The message Host Manager gives when I select NIS and try 
  to do an operation that might involve updating maps seems to 
  imply the lack of support for NIS updates has something to do 
  with mixed OS versions, and might change in the future.  Is 
  this true?
  
  A) No.  Programmatic updates to NIS are not possible with any
  combination of OS versions.  And so no admintool tools will 
  update NIS under any circumstances.
  
  The message Host Manager gives intends only to state that the 
  tool can't update NIS programmatically then tell the user how 
  to do so manually.  Unfortunately the message can be 
  interpreted more broadly than it was intended, and may 
  mislead some users.
  
  
  Q) Why can't the admintool tools update NIS automatically?
  
  A) The NIS protocol doesn't support updates by programs.  In 
  SunOS 4.x the only way to update NIS was to edit the files on 
  the NIS master then run `ypmake`.  Solaris isn't any 
  different.
  
  In fact, Solaris doesn't support `ypserv` at all.  Customers 
  are encouraged to migrate from NIS to NIS+.  NIS+ provides 
  much better security, better performance, and can be updated 
  by programs.  NIS+ supports a "NIS compatibility mode" to 
  ease the transition.
  
  
  Q) What does it mean to say a printer is a NIS+ Printer?
  
  A) Printer Manager maintains a list of "registered" printers 
  across a whole network as a convenience to system 
  administrators.  Typically system administrators will 
  register each locally attached printer in the list as they 
  set it up, then refer to that list later when setting up 
  remote access to printers for a client.
  
  The list of registered printers happens to be stored by NIS+, 
  and the label "NIS+" fits on the button better than the label
  "registered".  That's the only reason these printers may be 
  called NIS+ Printers.  The "lp" subsystem knows nothing about 
  the list of registered printers.  Registered printers don't 
  function any differently than unregistered printers.
  
  
  _____________________________________________________________
  
  
  
  IP interface
  
  Frequently asked Questions/Answers on Solaris 2.x,
  in the area of networks
  
  Q) Is there documentation that describes the interface 
  between IP and network drivers, namely, the SUN specific 
  requirements not outlined in the DLPI Version 2 
  specification?
  
  A) IP is a STREAMS module in Solaris 2.X. Any module or 
  driver interface with IP should follow the STREAMS 
  mechanism.There are no specific requirements for the 
  interface between IP and network drivers.
  
   
  Q) When an ifconfig device0 plumb is issued, the driver
  immediately receives a DL_INFO_REQ. Exactly what is required 
  in the DL_INFO_ACK from a Style 2 provider?
  
  A) Please look at 'dl_info_ack_t' struct in 
  /usr/include/sys/dlpi.h.
  
  
  Q) Is it possible for the driver to be a CLONE driver and 
  also a DLPI Style 2 provider?
  
  Yes.
   
  
  Q) If so, how do I map the minor number selected in the open 
  routine to an instance prior to a DL_ATTACH_REQ? The 
  technique of using the  minor number to obtain the instance 
  in the getinfo routine is not  valid prior to the 
  DL_ATTACH_REQ. How do you suggest this be handled?
  
  A)  The 'DL_ATTACH_REQ' request is to assign a physical point 
  of attachment(PPA) to a stream. The 'DL_ATTACH_REQ' request 
  can be  issued any time after a file or stream being opened. 
  I don't think  the 'DL_ATTACH_REQ' request has anything to do 
  with  assigning,  retrieving or mapping minor/instance 
  number. Of course, you can issue  a 'DL_ATTACH_REQ' request 
  for a file or stream with desired  major/minor number. To the 
  question of mapping minor number to instance, usually the 
  minor number(getminor(dev) is the instance number.
  
  
  Q) In the examples a minor node is created each time the 
  driver's attach routine is called. How would a CLONE driver 
  attach to multiple  boards, that is, have multiple instances, 
  and still only create one  minor node?
  
  A) For the CLONE driver, I don't know if it is possible to do 
  that. For the non-CLONE driver, it is possible to use the 
  bits information in a  particular minor number, for example 
  'FF', to map all other minor nodes.
   
  
  Q) Does Solaris 2.1 TCP/IP support Streams???
  
  A) Yes, The TCP and IP are STREAMS modules in Solaris 2.1. 
  The command 'strconf < /dev/tcp' will show you the modules.
  
   
  Q) Does SunOS 4.x TCP/IP support Streams??
  
  No.
   
  
  Q) Does Solaris 2.1 ethernet drivers support LLI 2.0 
  interfaces???
  
  A) Do you mean 'DLPI'(Data Link Provider interfaces) ?
  The Solaris 2.1 ethernet drivers, le and ie. both support 
  DLPI.  Please see man pages of le and ie.
   
  
  Q) Does Solaris 2.1 DLPI provide  both connection oriented 
  services and connection less services. Also, is your DLPI 
  Version 2.0, which includes multicast facilities.
  
  A) Yes and yes. Please see man page of 'dlpi'.
  
  Q) Is multicasting supported on SunOS 4.x? If not, how can 
  the customer obtain this feature?
  
  A) IP multicast is a standard supported feature in Solaris 
  2.x, but we don't support it in SunOS 4.x.  If the customer 
  wants to run an unsupported IP multicast on his/her SunOS 4.x 
  machines, it can be got from public domain object 
  distribution that Steve Deering, the inventor of IP 
  multicast, distributes.  This is available via anonymous FTP 
  from gregorio.stanford.edu in the file vmtp-ip/ipmulti-
  sunos41x.tar.Z.
  
  
  _____________________________________________________________
  
  
  
  Questions on RPC and TLI
  
  Frequently asked Questions/Answers on Solaris 2.x,
  in the area of networks
  
  
  Q) We are using the TLI functions such as t_open and t_bind 
  in one of our programs.  When we do a t_bind call, why do we 
  get an M_DATA ioctl  rather than an M_PROTO?  Do you intend 
  to do this permanently?
  
  A) The t_bind() function does local management, so M_DATA 
  ioctl is an appropriate message block.
  
  
  Q) I'm looking for RPC development kit for Macintosh. 
  Can you help?
  
  A) You probably could get those informations by calling 
  'Apple'.
  
  
  Q) Does Solaris 2.1 support XTI or TLI interfaces?
  
  A) Solaris 2.1 support TLI and will support XTI in the near 
  future. Please see "Solaris 2.1 Standards Conformance Guide". 
  You can do a search of 'TLI' on AnswerBook.
  
  
  Q) Does SunOS 4.1 support XTI or TLI interfaces?
  
  A) It supports TLI interfaces. Please see man pages of 
  't_open', 't_bind', 't_snd', 't_close' ... etc.
  
  
  _____________________________________________________________
  
  
  
  NFS interoperation
  
  Frequently asked Questions/Answers on Solaris 2.x,
  in the area of networks
  
  Q) With Solaris 2.x configured as a client, nfs mount with 
  with HP-UX or AIX machines will not work, even though 
  dfshares shows that the file systems are exported.The error 
  message "Server not responding" appears.
  
  A) The following workaround is suggested (to be done on 
  solaris 2.x machine):
  
          1. Append the following two lines into /etc/system
  
          set nfs:nfs_portmon=0
          set nfs:nfs_fastpath=0
  
          2. Cut the number of group that root belongs to 6 in 
  the /etc/group if this is the case. Usually it happens if 
  root belongs to 11 groups or more.