OpenStep (NeXT) and TTY modes

Nicolas Williams Nicolas.Williams at ubsw.com
Fri Nov 2 04:58:48 EST 2001


For what it's worth. People first noticed this problem here a while ago,
about a year even.

We found another problem with OpenSSH and OpenStep, more recently,
which we've reported to Apple: when running sshd standalone (not from
inetd), machines panic and then hang on reboot. Go figure. We don't
know what causes it. The workaround is to kill sshd before rebooting or
run sshd out of inetd. Again, this is white NeXT we're talking about (OS
4.2, w/ y2k patches, on x86 hw).

Nico

On Thu, Nov 01, 2001 at 10:37:20AM -0600, mouring at etoh.eviladmin.org wrote:
> 
> Hmm.. Baseline OpenStep 4.2 on NeXT Black Slab with the meger y2k patches
> put out before it transformed into Mac OS X.
> 
> I've not touched an OpenStep 4.2 White box in almost 4 years.
> 
> Still seems odd that they would react so differently, and yet no one else
> I've talked to running NeXT 3.x to OpenStep 4.x from x86 to Sparc has
> complained in over a year.
> 
> Can I get a few other people in the NeXT world that are still hanging
> around to give comments on this please?  Mainly those with x86, but anyone
> with HP, Sparc, or m68k comment if this causes any odd effects (check 'su'
> and 'telnet' of the box.. it has been an issue in the past before we moved
> to readpassphrase() on some NeXT versions).
> 
> I'm still about a month out until I can put my Slab back into working
> order.
> 
> - Ben
> 
> On Thu, 1 Nov 2001, Nicolas Williams wrote:
> 
> > Without those flags being set we get: a) no echo, b) no CR.
> >
> > The command that fixes the problem is "stty -nl echo".
> >
> > Perhaps there's something different about your OpenStep systems and
> > ours? (apart from the hw -- we use x86 hw).
> >
> > Nico
> >
> >
> > On Thu, Nov 01, 2001 at 09:25:06AM -0600, mouring at etoh.eviladmin.org wrote:
> > >
> > > I have to ask since I did the core NeXT work.. What issues are you seeing
> > > that adding the below 3 lines fix?
> > >
> > > I've been using the NeXT (OpenStep 4.2 and NeXTStep 3.3 on Black hardware)
> > > for about a year now without noticing any abnormal issues.
> > >
> > > - Ben
> > >
> > > On Wed, 31 Oct 2001, Nicolas Williams wrote:
> > >
> > > > Ok, the correct modes to add, before parsing the client-sent tty modes,
> > > > are:
> > > >
> > > > #ifdef HAVE_NEXT
> > > > 	tio.c_oflag |= ONLCR;
> > > > 	tio.c_lflag |= ECHO;
> > > > 	tio.c_iflag |= ICRNL;
> > > > #endif /* HAVE_NEXT */
> > > >
> > > > We've tested this change and find that it fixes the problem with tty
> > > > modes on OpenStep.
> > > >
> > > > Nico
> > > >
> > > >
> > > > On Wed, Oct 31, 2001 at 02:38:24PM -0500, Nicolas Williams wrote:
> > > > > OpenStep, apparently, does not initialize new pty/tty modes to a sane
> > > > > default.
> > > > >
> > > > > I'm thinking this code snippet, added to tty_parse_modes() before the
> > > > > for(;;) loop should suffice:
> > > > >
> > > > > #ifdef HAVE_NEXT
> > > > > 	tio.c_oflag |= ONLCR;
> > > > > 	tio.c_lflag |= ECHO;
> > > > > #endif /* HAVE_NEXT */
> > > > >
> > > > > Also, I've noticed that "ssh -t next_host stty" gives different output
> > > > > than an interactive session to the same NeXT... I suspect that this
> > > > > means that the SSH client is sending a different set of tty modes to the
> > > > > sshd on the NeXT... Is that so? Does that make sense?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Nico
> > > > > --
> > > > >
> > > > > Visit our website at http://www.ubswarburg.com
> > > > >
> > > > > This message contains confidential information and is intended only
> > > > > for the individual named.  If you are not the named addressee you
> > > > > should not disseminate, distribute or copy this e-mail.  Please
> > > > > notify the sender immediately by e-mail if you have received this
> > > > > e-mail by mistake and delete this e-mail from your system.
> > > > >
> > > > > E-mail transmission cannot be guaranteed to be secure or error-free
> > > > > as information could be intercepted, corrupted, lost, destroyed,
> > > > > arrive late or incomplete, or contain viruses.  The sender therefore
> > > > > does not accept liability for any errors or omissions in the contents
> > > > > of this message which arise as a result of e-mail transmission.  If
> > > > > verification is required please request a hard-copy version.  This
> > > > > message is provided for informational purposes and should not be
> > > > > construed as a solicitation or offer to buy or sell any securities or
> > > > > related financial instruments.
> > > > --
> > > >
> > > > Visit our website at http://www.ubswarburg.com
> > > >
> > > > This message contains confidential information and is intended only
> > > > for the individual named.  If you are not the named addressee you
> > > > should not disseminate, distribute or copy this e-mail.  Please
> > > > notify the sender immediately by e-mail if you have received this
> > > > e-mail by mistake and delete this e-mail from your system.
> > > >
> > > > E-mail transmission cannot be guaranteed to be secure or error-free
> > > > as information could be intercepted, corrupted, lost, destroyed,
> > > > arrive late or incomplete, or contain viruses.  The sender therefore
> > > > does not accept liability for any errors or omissions in the contents
> > > > of this message which arise as a result of e-mail transmission.  If
> > > > verification is required please request a hard-copy version.  This
> > > > message is provided for informational purposes and should not be
> > > > construed as a solicitation or offer to buy or sell any securities or
> > > > related financial instruments.
> > > >
> > > >
> > --
> >
> > Visit our website at http://www.ubswarburg.com
> >
> > This message contains confidential information and is intended only
> > for the individual named.  If you are not the named addressee you
> > should not disseminate, distribute or copy this e-mail.  Please
> > notify the sender immediately by e-mail if you have received this
> > e-mail by mistake and delete this e-mail from your system.
> >
> > E-mail transmission cannot be guaranteed to be secure or error-free
> > as information could be intercepted, corrupted, lost, destroyed,
> > arrive late or incomplete, or contain viruses.  The sender therefore
> > does not accept liability for any errors or omissions in the contents
> > of this message which arise as a result of e-mail transmission.  If
> > verification is required please request a hard-copy version.  This
> > message is provided for informational purposes and should not be
> > construed as a solicitation or offer to buy or sell any securities or
> > related financial instruments.
> >
> >
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the openssh-unix-dev mailing list