From: MERC::"uunet!ALIEN.GICI.COM!LAUT" 18-OCT-1992 23:03:45.27 To: galaxy::gleeve CC: Subj: RE: ln03r/telnet hack Glen, I would love to include the program for doing the LN03R hack. The only problem I would have is that it was written while I was under contract to a client, on the client's time. Technically, it belongs to the client, and I'm certain there would be intellectual property issues that need to be addressed. However, if I were to re-write it again, on my own time, it's likely that the program would find it's way onto the tape! I have to admit, it was fun to do, especially because I know how it would absolute *goad* the true-to-Mother-DEC residents we had at the time. The only problem you might encounter with it is that the thing is a terminal port driver, and is rather intimately married with Wollongong's WIN/TCP for VMS product. In fact, I had to reverse-engineer WIN/TCP slightly to figure out the symbolic calling parameters in order to have my driver call their driver via the CALLS instruction, and avoid all context switching into user mode. I ended up talking with the senior product engineer at Wollongong, who was rather impressed that I reverse-engineered his code, and had come up with this extention to his functionality. Presently, we're talking about adding Kerberos support. I don't know if Wollongong will be seriously interested or not in it. We'll see. As for me, one way or another, I *will* "screw up" VMS to fully integrate Kerberos authentication at all levels. For the first shot, I want to have a centralized authentication server that will handle a large VAXCluster, as well as any number of satellite VAXes out in the client's network. When a user is added to the authentication server, all the VAXes see it. Plus, we'll have login access control, object access control, etc., based upon which user and from where he is logging in at. If I can help it, we'll even simulate DECnet Proxy access functionality using Kerberos, but that is another step in itself. My stated desire is to make the VAXes an *integrated* player in our client's overall networking strategy -- but not a prima-dona. Of course, that is only the beginning. Like I said in my posting, after I get done with Kerberos, I'll likely work on implementing a TCP/IP equivalent of load balancing, similar to what the DECServers and DECnet does. This one I've already done the research on, and so it's just a matter of having the time and priority to begin working on it. Someday I also intend to implement OSPF under VMS. Because of the dynamic way that OSPF shifts the routing tables, I don't know if it can be made a separate entity from the in-core network kernel. IE, I don't know if, because of the massive routing changes possible, if I would have to directly map the routing tables into the OSPF module, or if I could get by with just using the Berkely calls to "externally" change the routing tables, much the way RIP or GATED would do. Something else you might be interested in for the SIG tape: One of the little annoyances in life I have against DEC is not being able to establish a dial-up circuit for TCP/IP or DECnet traffic through a DECServer. The thought occured to me that I could easily remedy that problem by creating *yet another* terminal driver, this time implementing both the port and class functionality, and using the class functionality to remap the LAT port drivers on either end of a dialup connection. Then, pumpt the packets through. Viola! No more problems dialing up through a DECServer. And if I were really sneaky (which I am), I might even make the driver simulate an Ethernet controller, so that you could reconfigure your end-node DECnet licensed stuff to plop onto this driver, and it would shoot the packets out into both the physical Ethernet driver, and also out through the serial line. Hmmm, maybe an LAVC over 19.2K modem. The possibilities tingle the imagination... (heh, heh, heh) Maybe I'll post this last idea onto "comp.os.vms" and see if I generate any discussions... Oh well, gotta run. Have to wake up bright and early for work tomorrow morning! -- Bill Laut Internet: laut@alien.gici.com Gull Island Consultants, Inc. Phone: (616) 780-3321 Muskegon, MI 49440 >> "Usual disclaimers, apply within" << "Praise the Lord from the earth, ye dragons and all deeps." Psalm 148:7