Yesterday, Casper wrote:
>Mike <email@invalid.hostname> writes:
>
>>While messing with some communications s/w as root, I appear to have
>>inadvertently changed the default terminal characteristics of some
>>of the /dev/pts devices.
>
>Check /kernel/drv/options.conf; it is the only place I know of
>which stores "defaults" for terminals.

	Thanks Casper, I wondered where the defaults were.  But
	no, that file has not been touched.

>>(Symptoms are that when opening the same subset of /dev/pts devices
>>say by xterm, in.telnetd etc., these subset of pts devices always
>>`initialise' with their characteristics wrong.)
>
>So it is a particular set of devices which has problmes?  Then
>check to see if there's anything strange in /dev/pts (strange links,
>strange ling targers)

	Yes, its particular set of terminals.  I haven't checked
	whether the number of strange ones is increasing though
	it feels that way, but as I say I can't confirm that.
>
>>How to reset the weird pts devices back to sane defaults?  Are the
>>defaults stored in some template for each minor device?  Is it a
>>case of copying the template of one of the many good ones to one of
>>the handful of screwed-up ones?
>
>No, there's no template for each device; is this problem
>persistant across reboots?

	I haven't rebooted recently.
>
>Does the software run and claims to own some of the devices?
>
	All of the devices in /dev/pts are owned and grouped root.

	The software is an old Solaris binary of `rtn' a reverse
	terminal server.  I give it an alias, say /dev/myalias,
	which it associates with a telnet connection to a given
	ip address and tcp port.  I create two such aliases:

	/dev/myalias1	-> terminalserver1.somewhere.net:port1
	/dev/myalias2	-> terminalserver1.somewhere.net:port2

	It links myalias1 and myalias2 to next available /dev/pts.

	Both network connections are made, but only one of them,
	the first setup, is operative.  Run in debug mode, it
	complains as follows when the second pseudoterminal is
	setup:

1081716708554381 ERROR: Unable to reuse master pty on multiplexed device.

	The command that invokes the reverse telnet daemon is run as
	root.  /dev/myaliases are root.other, and the ultimate
	targets /devices/pseduo/pts@0:nn are root.tty and look fine.
	However, its only since using `rtn' - creating and tearing
	down network connections and /dev links - that I've seen the
	problem.

	I need simultaneous access, via different pseudoterminal
	aliases, to more than one port on a remote terminal server.
	`rtn' is only giving me one, so I'm looking for a replacement
	anyway.

	Anyone have a copy of csportd for Solaris?

	Thanks for your suggestions Casper.

	Mike.

Mike <email@invalid.hostname> writes:

>	/dev/myalias1	-> terminalserver1.somewhere.net:port1
>	/dev/myalias2	-> terminalserver1.somewhere.net:port2

>	It links myalias1 and myalias2 to next available /dev/pts.

The problem with pts style ptys is that they don't have a 1-1
master slave relationship not a predictable order of issuing
(the Solaris 8 and later kernel may reuse them more randomly)

>	Both network connections are made, but only one of them,
>	the first setup, is operative.  Run in debug mode, it
>	complains as follows when the second pseudoterminal is
>	setup:

>1081716708554381 ERROR: Unable to reuse master pty on multiplexed device.

>	The command that invokes the reverse telnet daemon is run as
>	root.  /dev/myaliases are root.other, and the ultimate
>	targets /devices/pseduo/pts@0:nn are root.tty and look fine.
>	However, its only since using `rtn' - creating and tearing
>	down network connections and /dev links - that I've seen the
>	problem.

>	I need simultaneous access, via different pseudoterminal
>	aliases, to more than one port on a remote terminal server.
>	`rtn' is only giving me one, so I'm looking for a replacement
>	anyway.

>	Anyone have a copy of csportd for Solaris?


Have you tried using the BSD ptys instead?  They're better suited
for fixed master/slave setups.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.