home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / novell / 10492 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  2.7 KB
  1. Path: sparky!uunet!crdgw1!newsun!donp
  2. From: donp@novell.com (don provan)
  3. Newsgroups: comp.sys.novell
  4. Subject: Re: LANSUP.COM mistakenly reverses MAC address bit order.
  5. Message-ID: <1992Dec14.180121.5339@novell.com>
  6. Date: 14 Dec 92 18:01:21 GMT
  7. References: <1992Dec13.164000.13941@bernina.ethz.ch>
  8. Sender: news@novell.com (The Netnews Manager)
  9. Organization: Novell, Inc., San Jose, California
  10. Lines: 45
  11. Nntp-Posting-Host: na.sjf.novell.com
  12.  
  13. In article <1992Dec13.164000.13941@bernina.ethz.ch> pkarrer@bernina.ethz.ch (Peter Karrer) writes:
  14. >Now, LANSUP.COM tells me:
  15.  
  16. Well, i really can't answer your question since i don't know the first
  17. thing about "LANSUP", whatever that is, but never one to leave a
  18. theoretical explanation unturned....
  19.  
  20. >Sure enough, when I trace IP traffic, I see that the MAC header source
  21. >address is correct, while the ARP reply address has its bits swapped...
  22.  
  23. The technical term for what you're describing here is "canonical
  24. order".  As you may know, Ethernet and Token-Ring transmit the bits in
  25. each byte in a different order.  Normally this doesn't matter, but
  26. when a bridge is placed between an Ethernet and a Token-Ring, those
  27. MAC addresses transmitted as data, such as the MAC addresses in the
  28. ARP packets you're looking at, become a problem.  The solution within
  29. the industry is to adopt a "canonical order" so that any MAC address
  30. transmitted in data is always passed in the order it would be passed
  31. on Ethernet.  Hence your bit flipped MAC addresses.
  32.  
  33. The other side of the story is that, although canonical order is
  34. widely recognized as the "right" thing to do, there is a very large
  35. installed base of Token-Ring software written and deployed before
  36. canonical order was invented.  This makes it nearly impossible to
  37. actually *use* canonical order on any given Token-Ring.  When
  38. implemented at all, it's almost always optional.  In fact, native
  39. order is almost always the default.
  40.  
  41. >The problem probably comes from the fact that support for 802.5 NDIS drivers
  42. >is a new feature of LAN Support Program version 1.3x; earlier versions
  43. >only supported 802.3 and DIX 2.0, for which bit swapping is OK.
  44.  
  45. Not quite.  In 802.3 and DIX, the bit swapping just isn't necessary.
  46. The normal MAC addresses are already in canonical order on 802.3 nets.
  47.  
  48. >I think LANSUP.COM needs an upgrade, or is there some workaround?
  49.  
  50. As i say, i know nothing about LANSUP, but my guess is that there's a
  51. command line switch of some sort.  I can't imagine why else there'd be a
  52. single bit to control the order except to support a switch to let the
  53. user set the flag one way or the other.  Since you're already poking
  54. around disassmbling the code, you might see if you can find that switch.
  55.  
  56.                         don provan
  57.                         donp@novell.com
  58.