home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume20 / etherlib / part02 / SunBugs < prev   
Encoding:
Text File  |  1989-10-24  |  1.9 KB  |  41 lines

  1. This is a description of a bug in SunOS 4.0 NIT, which is not fixed in 4.0.3
  2.  
  3. 1016994: Public Summary:
  4. 1016994:    The ifpromisc() routine of net/if.c, which handles
  5. 1016994:    transitions into and out of promiscuous mode by
  6. 1016994:    keeping track of the number of outstanding requests
  7. 1016994:    there are for the mode and calling the interface driver
  8. 1016994:    to change mode on transitions to and from zero
  9. 1016994:    has a bug that causes it to disable promiscuous
  10. 1016994:    mode whenever it is called to disable the mode and
  11. 1016994:    the number of outstanding requests for the mode is
  12. 1016994:    greater than one.
  13. 1016994:    The problem occurs only when there are more than one
  14. 1016994:    concurrent requesters for promiscuous mode for a
  15. 1016994:    particular interface (i.e. run multiple etherfind's
  16. 1016994:    on the same interface in parallel, then terminate
  17. 1016994:    one of the processes).
  18. 1016994: Hook 2:  Needs investigation in release: 4.0.4, 4.0.4c
  19.  
  20. This can cause interfaces to go out of promiscuous mode when they shouldn't;
  21. promiscuous mode reception may fail as a result.  This also impacts the
  22. reception of multicast addresses with this library, since that is implemented
  23. on Suns with promiscuous mode reception and filtering.
  24.  
  25. The only workaround seems to be to close all promiscuous mode file descriptors
  26. in all processes, then reopen them.  Just setting the IFF_PROMISC bit with a
  27. SIOCSIFFLAGS ioctl doesn't seem to help.
  28.  
  29.  
  30.  
  31. This is a description of a bug in SunOS 4.0.3 NIT.
  32.  
  33. The NIT interface now receives broadcast packets sent from the local machine,
  34. but their ethernet source field will sometimes contain a random value.  The
  35. packets as sent out on the ethernet are correct, but the NIT interface
  36. sometimes receives them incorrectly.
  37.  
  38. You can tell if this bug affects you by running "etherfind -p -arp" and then
  39. pinging a nonexistent (or down) host.  If you have the bug, you will see lots
  40. of arp packets from strange hosts.  There is no known workaround.
  41.