steveg@hammer.UUCP (Steve Glaser) (05/27/84)
The NSC driver mentioned in System V is not included in the source. AT&T ships the manual page, but not the source. They also do this for X.25 support and syncronous terminal support [st(7), st(1), stlogin(1), stgetty(1) and ststat(1)]. In some cases they give you the include files or zero length soruce files (I guess that makes it easier to keep make happy). The 4.2 Hyperchannel driver I wrote has undergone major changes since the copy on the 4.2 distribution tape. If anyone wants a new copy, let me know. I'm going to send a new copy back to Berkeley once we get the latest problem figured out. I'l post a note to unix-wizards when I do. Aside: current problem is that tcp connections routed through an A710 microwave link adapter keep timing out and get really bad preformance [10K baud from one unloaded 780 to another over a 1.544 Mbit microwave link (T1 carrier)]. I think the problem has something to do with 4.2 TCP adaptive retransmission algorithm interacting with the "half-duplex" nature of the A710 microwave link (the link is really full duplex, but the A710 only uses it as a half duplex connection). New features from the one distributed with 4.2 bsd: - it works. Berkeley changed the ioctl interface between 4.1a and 4.2. The new one limits the ioctl data area to 128 bytes. The old hy driver used a bit over 512 bytes when setting the route table, your 4.2 will crash if you try to set the hyperchannel route table. - powerfail detect on the PI-13 is better handled. - ifconfig is better supported. If you rerun ifconfig on the driver, it "kicks" the hardware and throwas away any pending packets to be transmitted. It's ugly, but it's better than rebooting to get the hyperchannel back to life. - the driver now supports loopback off the remote end of an A710 link adapter in addition to loopback through the local end of all adapters (A710, A410 and A110 for sure, probably others but I don't have any of those around to verify against). - a rudimentary raw socket interface to the hyperchannel hardware is provided. This is UNTESTED as yet (but the folks at Nasa/Ames are looking into it). The intention is to allow user programs to send arbitrary packets to remote adapters (to gather statistics, configure link adapter tables, etc.). It should also be able to talk foreign protocols (e.g. talk to a CRAY) if the protocol in question follows a few simple rules (mostly, the driver limits you to one associated data buffer per message proper, also we invented a packet type field since NSC didn't specify one - this may clash with other usage of that word). When I send the new driver on to Berkeley, I'll post a note to this forum. Note that the Hyperchannel driver is a spare time project with me. Work gets done in spurts to correct specific problems (and only when I can locate the time). As usual, this software is warranty free - we're interested in finding out who's using it and interested in problems encountered, but don't commit to any support, etc. in it again. Steve Glaser Tektronix, Inc M/S 61-215 Box 1000 Willsonville, OR 97070 (503) 685-2562 tektronix!steveg steveg.tektronix@csnet-relay.csnet