NSC PI-13 or DEC DR11-B driver wanted/4.2 hy driver update

[Steve Glaser]

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 at csnet-relay.csnet