thompson@pan.ssec.honeywell.com (John Thompson) (02/23/91)
Hi all -- A couple of days ago I hit the net w/ a TCP/IP quibble/question, and the reason behind it, which was a FLAME of Cadence's license manager. I'd like to follow up w/ the results of this posting. First, I got a couple of suggestions on how to fix the TCP hostname, and on how to get around Cadence's license-manager not liking named (the reason that I wanted to muck over the TCP stuff in the first place). It turns out that the node had the decency to crash on me, and therefore the TCP/IP was nicely wiped completely clean. :-) Since I'd put in the changes to make it not use named, it got re-started correctly. (The problem is that a node 'remembers' what it's been called. Even after thoroughly trashing TCP, and restarting it, when I 'pinged' one of the interfaces, it would respond with its old name. If I pinged the new name, it would respond w/ the old one too.) All suggestions on how to make the node forget this info failed to work. It must be somewhere deep that HP/Apollo hides some info. Secondly, I apparently raised a small whirlwind of activity at Cadence and with some of their customers. I just talked w/ the corporate A.E. for networking and license brokers (I hope that's roughly his title). We discussed my problems/complaints/concerns, and got some things resolved, some things clarified, and some action items. Basically, the problems I have w/ the Cadence server are twofold. First, I had the impression that they had written their own routine to do gethostbyname(). That is apparently false. However, since they statically bind all needed routines in before shipping, it does mean that (1) people who muck around w/ system software may get burned and (2) people whose systems are updated may be burned too. It might be that the latter is the case, but it appears that the bulk of the errors are coming about because _after_ the gethostbyname() call, the name returned is not stripped of its domain before a comparison, and because the host NAMES are compared, not the addresses. We had problems because, w/ name-service running, the node returns a hostname of 'elrond.ssec.honeywell.com' (e.g.) and the cdsServer is looking for just 'elrond'. It gets worse if the 'official' name of the node is something like 'pan.ssec.honeywell.com', and 'elrond' is just a nickname. SUpposedly, a new version of the license-server / lock-mgr (cdsServer) will fix these problems. We have the 2.1_f2 version for Motorola's and will verify or refute that claim this weekend. The problem is supposed to completely go away w/ the next major release (4.0). (Of course, the next release is _always_ perfect. :-) In short (50 lines?), I had a pretty good talk w/ Tim Kiphuth, and he seemed to be genuinely concerned w/ the resolution of our problems and complaints, and not just interested in avoiding bad press. Here's hoping that the new stuff works perfectly, that the days are sunny and bright, and that all evil people in the world repent and are saved. (I'd put better odds on the last one. :-) :-) :-) :-) :-) -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com Me? Represent Honeywell? You've GOT to be kidding!!!