home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / hp / 8557 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  2.6 KB
  1. Path: sparky!uunet!mcsun!corton!enst!ulysse!philipp
  2. From: philipp@ulysse.enst.fr (Philippe-Andre Prindeville)
  3. Newsgroups: comp.sys.hp
  4. Subject: Bug in LLA/SNAP and porting Appletalk to HP-UX 8.05/7
  5. Keywords: appletalk, LLA, SNAP
  6. Message-ID: <2392@ulysse.enst.fr>
  7. Date: 26 Jul 92 21:42:02 GMT
  8. References: <92206.15:50:38.186934.B03@vm.urz.uni-heidelberg.de>
  9. Reply-To: philipp@res.enst.fr (Philippe-Andre Prindeville)
  10. Organization: Telecom Paris, France
  11. Lines: 51
  12.  
  13. I'm trying to port CAP 6.0 (Columbia University's Appletalk
  14. package) to HP-UX 8.0.  There is an option to use either IP
  15. encapsulated Appletalk (called IPTalk) or to "go native" and
  16. use Appletalk directly over Ethernet (called EtherTalk).
  17.  
  18. Being a brave network hacker (cough), I rolled up my sleeves
  19. and said, "Well, let's get this done before dinner."
  20.  
  21. Not quite.  First off, I found out that Ethertalk uses SNAP
  22. encoding (SSAP&DSAP == 0xaa).  Good.  8 bytes wasted for
  23. nothing.  Oh well.  So then I changed my code to use SAP
  24. encoding.  The doc says that codes 6, 248, and 252 are reserved.
  25. Fine.  I want 170 (0xaa).  I run my code and...  Device busy.
  26.  
  27. Hmmm.  Probably that brain-dead habit of using SNAP encapsulation
  28. of IP, I say to myself.  Quickly remedied:
  29.  
  30. % lanconfig lan0 ether -ieee
  31.  
  32. and I try it again:  Device busy.
  33.  
  34. I looked for background daemons that might be using this SSAP,
  35. and none are present.  Or none that are obvious.  I went into a
  36. rage and killed everything that might be tying up the device.
  37. No such luck.
  38.  
  39. Other SSAPs work fine.  Strange.  So, my conclusion is that
  40. something in the kernel (probably IP) gets its hooks into the
  41. device driver and doesn't free it.
  42.  
  43. Since SNAP encapsulation is used often enough, you would think that
  44. HP could add one more IOCTL/NETCTRL to their list that allows a
  45. user to specify the TYPE field of SNAP (ie. provide a client hook
  46. to SNAP like they did for raw SSAP/DSAPs).  IP doesn't use *all*
  47. of them, only 0x0800 and the HPprobe-thingy.
  48.  
  49. You would also think that writev()s work with LLA sockets.  No
  50. where in the doc does it say they do, but thankfully, they do.
  51.  
  52. I think SNAP encapsulation is brain-dead, especially if you don't
  53. have FDDI.  But anyway...  Does anyone have a work around to this
  54. SNAP conflict?  It would be nice if multiple clients could use SNAP.
  55.  
  56. I've noticed that there is a libatalk.a file in /etc/conf.  If you
  57. add "atalk" to your dfile, it gets compiled in.  But no where is
  58. there an API on programming this code.  The code seems to have been
  59. lifted from Kinetics or Stanford.  Does anyone have a handle on
  60. docs?  If I can't get LLA/SNAP working, I might have to use the (no
  61. doubt ancient) version of Appletalk distributed by HP.
  62.  
  63. -Philip
  64.