Re: Serial terminal (not console)

2014-01-28 Thread Zé Loff
On Tue, Jan 28, 2014 at 03:27:55AM -0500, Hugo Villeneuve wrote:
> On Mon, Jan 27, 2014 at 10:57:59AM +, Zé Loff wrote:
> > On Thu, Jan 23, 2014 at 10:47:05AM +, Zé Loff wrote:
> > > Sorry if it's a dumb question, but I'm stuck...
> > > 
> > > I have two machines (yesterday's current, one i386, one amd64) and I can
> > > properly setup a serial console on the i386 and access it on the amd64
> > > (i.e. changes in boot.conf and /etc/ttys as per the FAQ). This tells me
> > > that the cable is OK, that there are no IRQ issues going on, that it all
> > > works at the set baud rate (9600), etc...
> > > 
> > > However, I can't get a simple terminal on the same tty device (i.e. not
> > > the system's console). Without a /etc/boot.conf file, and an otherwise
> > > vanilla /etc/ttys except for the following line
> > > 
> > >   tty00 "/usr/libexec/getty std.9600" vt100 on secure
> > > 
> > > I don't get a login prompt when connecting on the other machine, even if
> > > ps shows that there is a getty instance running for tty00.
> > > 
> > > The ultimate goal is to be able to manage a couple of "com
> > > port-impaired" HP MicroServers using a couple of ATEN USB serial
> > > adapters, which can't be used for serial consoles for obvious reasons.
> > > That's why I need to get a login on a serial terminal other than the
> > > system's console...
> > > 
> > > Any clues? 
> > > Thanks in advance
> > > Zé
> > > 
> > 
> > Sorry for insisting, but no one has a hint of why with this /etc/ttys
> > 
> > # name  getty   typestatus  comments
> > console "/usr/libexec/getty std.9600"   vt100   on  secure  <---
> > tty00 "/usr/libexec/getty std.9600" vt220 off   <---
> > ...
> > 
> > and this /etc/boot.conf
> > 
> > stty com0 9600 
> > set tty com0
> > 
> > I can remotely connect, but with this /etc/ttys
> > 
> > # name  getty   typestatus  comments
> > console "/usr/libexec/getty std.9600"   vt220   off  secure <---
> > tty00 "/usr/libexec/getty std.9600" vt100 on  secure<---
> > ...
> > 
> > and no /boot.conf I can't? Cluebats welcome.
> > 
> 
> I think what is tagged as "console" automatically gets the "local"
> flag set. Altough, my whole experience with serial console is with
> sparc/vax not i386/amd64, things may differ in that world.
> 
> Try in /etc/ttys:
> 
> tty00 "/usr/libexec/getty std.9600" vt100 on  secure local
> 
> 
> If you don't want to reboot, look at ttyflags(8).
> 
> Good luck.
> 

That did it, thanks.

-- 



Re: Serial terminal (not console)

2014-01-28 Thread Hugo Villeneuve
On Mon, Jan 27, 2014 at 10:57:59AM +, Zé Loff wrote:
> On Thu, Jan 23, 2014 at 10:47:05AM +, Zé Loff wrote:
> > Sorry if it's a dumb question, but I'm stuck...
> > 
> > I have two machines (yesterday's current, one i386, one amd64) and I can
> > properly setup a serial console on the i386 and access it on the amd64
> > (i.e. changes in boot.conf and /etc/ttys as per the FAQ). This tells me
> > that the cable is OK, that there are no IRQ issues going on, that it all
> > works at the set baud rate (9600), etc...
> > 
> > However, I can't get a simple terminal on the same tty device (i.e. not
> > the system's console). Without a /etc/boot.conf file, and an otherwise
> > vanilla /etc/ttys except for the following line
> > 
> >   tty00 "/usr/libexec/getty std.9600" vt100 on secure
> > 
> > I don't get a login prompt when connecting on the other machine, even if
> > ps shows that there is a getty instance running for tty00.
> > 
> > The ultimate goal is to be able to manage a couple of "com
> > port-impaired" HP MicroServers using a couple of ATEN USB serial
> > adapters, which can't be used for serial consoles for obvious reasons.
> > That's why I need to get a login on a serial terminal other than the
> > system's console...
> > 
> > Any clues? 
> > Thanks in advance
> > Zé
> > 
> 
> Sorry for insisting, but no one has a hint of why with this /etc/ttys
> 
>   # name  getty   typestatus  comments
>   console "/usr/libexec/getty std.9600"   vt100   on  secure  <---
>   tty00 "/usr/libexec/getty std.9600" vt220 off   <---
>   ...
> 
> and this /etc/boot.conf
> 
>   stty com0 9600 
>   set tty com0
> 
> I can remotely connect, but with this /etc/ttys
> 
>   # name  getty   typestatus  comments
>   console "/usr/libexec/getty std.9600"   vt220   off  secure <---
>   tty00 "/usr/libexec/getty std.9600" vt100 on  secure<---
>   ...
> 
> and no /boot.conf I can't? Cluebats welcome.
> 

I think what is tagged as "console" automatically gets the "local"
flag set. Altough, my whole experience with serial console is with
sparc/vax not i386/amd64, things may differ in that world.

Try in /etc/ttys:

tty00 "/usr/libexec/getty std.9600" vt100 on  secure local


If you don't want to reboot, look at ttyflags(8).

Good luck.



Re: Serial terminal (not console)

2014-01-27 Thread Zé Loff
On Thu, Jan 23, 2014 at 10:47:05AM +, Zé Loff wrote:
> Sorry if it's a dumb question, but I'm stuck...
> 
> I have two machines (yesterday's current, one i386, one amd64) and I can
> properly setup a serial console on the i386 and access it on the amd64
> (i.e. changes in boot.conf and /etc/ttys as per the FAQ). This tells me
> that the cable is OK, that there are no IRQ issues going on, that it all
> works at the set baud rate (9600), etc...
> 
> However, I can't get a simple terminal on the same tty device (i.e. not
> the system's console). Without a /etc/boot.conf file, and an otherwise
> vanilla /etc/ttys except for the following line
> 
>   tty00 "/usr/libexec/getty std.9600" vt100 on secure
> 
> I don't get a login prompt when connecting on the other machine, even if
> ps shows that there is a getty instance running for tty00.
> 
> The ultimate goal is to be able to manage a couple of "com
> port-impaired" HP MicroServers using a couple of ATEN USB serial
> adapters, which can't be used for serial consoles for obvious reasons.
> That's why I need to get a login on a serial terminal other than the
> system's console...
> 
> Any clues? 
> Thanks in advance
> Zé
> 

Sorry for insisting, but no one has a hint of why with this /etc/ttys

#
#   $OpenBSD: ttys,v 1.18 2008/01/09 17:39:42 miod Exp $
#
# name  getty   typestatus  comments
#
console "/usr/libexec/getty std.9600"   vt100   on  secure  <---
ttyC0   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC1   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC2   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC3   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC4   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC5   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC6   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC7   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC8   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC9   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCa   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCb   "/usr/libexec/getty std.9600"   vt220   off secure
tty00 "/usr/libexec/getty std.9600" vt220 off   <---
...

and this /etc/boot.conf

stty com0 9600 
set tty com0

I can remotely connect, but with this /etc/ttys

#
#   $OpenBSD: ttys,v 1.18 2008/01/09 17:39:42 miod Exp $
#
# name  getty   typestatus  comments
#
console "/usr/libexec/getty std.9600"   vt220   off  secure <---
ttyC0   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC1   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC2   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC3   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC4   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC5   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC6   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC7   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC8   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC9   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCa   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCb   "/usr/libexec/getty std.9600"   vt220   off secure
tty00 "/usr/libexec/getty std.9600" vt100 on  secure<---
...

and no /boot.conf I can't? Cluebats welcome.

Thanks in advance
Zé


dmesg:

OpenBSD 5.5-beta (GENERIC) #233: Mon Jan 20 15:47:05 MST 2014

t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 300 
MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,PERF
real mem  = 200765440 (191MB)
avail mem = 185614336 (177MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @ 0xfc4c0
apm0 at bios0: Power Management spec V1.2
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1320/128 (6 entries)
pcibios0: PCI Interrupt Router at 000:05:0 ("Intel 82371FB ISA" rev 
0x00)
pcibios0: PCI bus #21 is the last bus
bios0: ROM list: 0xc/0xc000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX" rev 0x02
vga1 at pci0 dev 4 function 0 "Neomagic Magicgraph NM2200" rev 0x12
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: scree

Re: serial terminal

2007-05-31 Thread Maurice Janssen
On Wednesday, May 30, 2007 at 11:30:56 -0400, Woodchuck wrote:
>   3) There are null modem cables, and there are null modem
>cables.  Some are just plain junk, providing only cross over of the
>two data pins and if you're lucky, a ground.  Others implement
>various ideas of what a null modem cable should be; the opinions
>of what a null modem cable differed between Digital, who made your
>terminal and IBM, who designed the PeeCee.

Thanks to all for your reply.  This appeared to be the problem.  I've
used this cable for quite some time and thought it was OK, but it
wasn't.  Another nullmodem cable worked fine.

Maurice



Re: serial terminal

2007-05-31 Thread Stuart Henderson
On 2007/05/29 22:06, Maurice Janssen wrote:
> and sent -HUP to init.  There's a getty process on tty00, but there's
> no login: prompt on the terminal.  Everything I type on the terminal is
> echoed on the screen, so the cable is OK (local echo is off).

getty waits for an incoming connection

> The funny thing is, when I start 'tip tty00' on the machine (while
> logged in at the keyboard+monitor), the login: prompt appears on the
> terminal.

tip sets the modem control lines

> I suspected a problem with the permissions of the tty00 device.  After
> logout, they are set to
> crw---  1 root  wheel8,   0 May 29 21:44 tty00
> When logged in it is set to
> crw---  1 maurice  tty8,   0 May 29 22:00 tty00

that's right

> ksh: No controlling tty (open /dev/tty: Device busy)

tip probably has control

> Any ideas what's going wrong?

cable not wired correctly? try telling the system it's a local (not
modem) connection - add 'local' to /etc/ttys



Re: : serial terminal

2007-05-31 Thread Raimo Niskanen
Another issue that may be interesting:

Is this a server-like PC where you can tweak the serial console
usage from the BIOS?

I saw strange behaviour on a HP ProLiant DL145 G2 (I think) where
for some configuration of the serial BIOS console, the login
promp from OpenBSD on the serial port came and went depending on
if I attached to the telnet-emulated-through-BIOS serial console
through the Integrated Lights-Out ethernet connector.

Bottom line. Are there interesting BIOS settings for serial console?



On Wed, May 30, 2007 at 11:30:56AM -0400, Woodchuck wrote:
> On Tue, 29 May 2007, Maurice Janssen wrote:
> 
> > Hi,
> > 
> > I'm trying to use a VT420 serial terminal on an i386 box running
> > 4.1-stable.  Not as a system console, just as an extra screen to login.
> > The output of the boot loader and kernel output should go to the
> > monitor, as usual.
> > 
> > The terminal is hooked up to the first serial port with a null modem
> > cable.  I changed the tty00 line of /etc/ttys to:
> > tty00   "/usr/libexec/getty std.9600"   vt220   on  secure
> > and sent -HUP to init.  There's a getty process on tty00, but there's
> > no login: prompt on the terminal.  Everything I type on the terminal is
> > echoed on the screen, so the cable is OK (local echo is off).
> 
> H.  Look into two things, no, make that three:
> 
>   1) The settings on the terminal, whether XON/XOFF or RTS/CTS
> synchronization is selected, also baud rate, parity, 8/7 bits.  Try
> 8 bits, No parity, 1 stop bit ("8N1").
> 
>   2) The settings on the tty, from # stty -a /dev/tty00 when
> the getty is running.
> 
>   3) There are null modem cables, and there are null modem
> cables.  Some are just plain junk, providing only cross over of the
> two data pins and if you're lucky, a ground.  Others implement
> various ideas of what a null modem cable should be; the opinions
> of what a null modem cable differed between Digital, who made your
> terminal and IBM, who designed the PeeCee.
> 
> > The funny thing is, when I start 'tip tty00' on the machine (while
> > logged in at the keyboard+monitor), the login: prompt appears on the
> > terminal.
> 
> Yeah, this is weird.  You should be able to get the login: prompt
> by at most hitting the carriage return on the 420 twice.  Try to
> set up everything for XON/XOFF flow control.
> 
> > When I quit tip, I can login at the terminal.  When I logout from the
> > terminal, the login: prompt doesn't appear (but everything I type is
> > echoed to the terminal screen as before).  I can start tip again, and
> > then the login: prompt shows up again.
> > 
> > I suspected a problem with the permissions of the tty00 device.  After
> > logout, they are set to
> > crw---  1 root  wheel8,   0 May 29 21:44 tty00
> 
> This, by default, should be  uucp.dialer, permissions crw-rw---,
> when "at rest".  When a getty is running, it should be as shown here.
> 
> > When logged in it is set to
> > crw---  1 maurice  tty8,   0 May 29 22:00 tty00
> > Not sure if this is what it should be, but it doesn't look strange to
> > me.
> > 
> > BTW: not sure if it is related, but when I login as normal user, the
> > following warning is shown on the terminal:
> > ksh: No controlling tty (open /dev/tty: Device busy)
> > ksh: warning: won't have full job control
> > When I login as root, I don't get this warning.
> 
> Ick.  I have my suspicions, but won't voice them since they are
> superstitious.  They involve a brief trip to single-user mode and
> running  cd /dev; sh MAKEDEV all.
> 
> > Any ideas what's going wrong?
> 
> Yeah, you're using a serial terminal on a PeeCee. (sarcasm).
> 
> You are in a maze of twisty little passages, all alike. The
> lamp grows dimmer. (Zork, a metaphor for debugging RS-232).
> 
> Install a terminal emulator on the box, like kermit or something
> like minicom, from ports if the sometimes goofy behavior of tip/cu
> annoys you (like killing its parent xterm when you give it ~.).
> Hook up the terminal.  See what you can do.  Try things (settings).
> Terminals are a PITA, as bad as serial printers.  See if the 420
> has a VT-220 emulation mode, if so try it.  It's hard to debug them
> "over the phone" (by email) like this, one needs to poke and try.
> A RS232 line analyzer is real handy.  There used to be various
> utilities for MS-DOS that would display line status of the com ports
> on the screen, much like the blinkenlights on a modem.  Don't know
> it they exist for Unix.  Could kermit have such a feature?  One has
> to delve into the kernel to see these things, a forbidden zone in
> Unix, unless some happy ioctl to pccom exists.
> 
> Helpful man pages: tty, tip, remote, cu, getty, gettytab, pccom
> 
> With the getty killed, try catting a "large" text file to 
> /dev/tty00 (as root), look for garbage on the terminal, a sign
> of flow control being wrong.  Try this with the terminal set
> for "smooth scrolling".
> 
> A debugging test:  use the same cable (if you can) and c

Re: serial terminal

2007-05-30 Thread Woodchuck
On Tue, 29 May 2007, Maurice Janssen wrote:

> Hi,
> 
> I'm trying to use a VT420 serial terminal on an i386 box running
> 4.1-stable.  Not as a system console, just as an extra screen to login.
> The output of the boot loader and kernel output should go to the
> monitor, as usual.
> 
> The terminal is hooked up to the first serial port with a null modem
> cable.  I changed the tty00 line of /etc/ttys to:
> tty00   "/usr/libexec/getty std.9600"   vt220   on  secure
> and sent -HUP to init.  There's a getty process on tty00, but there's
> no login: prompt on the terminal.  Everything I type on the terminal is
> echoed on the screen, so the cable is OK (local echo is off).

H.  Look into two things, no, make that three:

1) The settings on the terminal, whether XON/XOFF or RTS/CTS
synchronization is selected, also baud rate, parity, 8/7 bits.  Try
8 bits, No parity, 1 stop bit ("8N1").

2) The settings on the tty, from # stty -a /dev/tty00 when
the getty is running.

3) There are null modem cables, and there are null modem
cables.  Some are just plain junk, providing only cross over of the
two data pins and if you're lucky, a ground.  Others implement
various ideas of what a null modem cable should be; the opinions
of what a null modem cable differed between Digital, who made your
terminal and IBM, who designed the PeeCee.

> The funny thing is, when I start 'tip tty00' on the machine (while
> logged in at the keyboard+monitor), the login: prompt appears on the
> terminal.

Yeah, this is weird.  You should be able to get the login: prompt
by at most hitting the carriage return on the 420 twice.  Try to
set up everything for XON/XOFF flow control.

> When I quit tip, I can login at the terminal.  When I logout from the
> terminal, the login: prompt doesn't appear (but everything I type is
> echoed to the terminal screen as before).  I can start tip again, and
> then the login: prompt shows up again.
> 
> I suspected a problem with the permissions of the tty00 device.  After
> logout, they are set to
> crw---  1 root  wheel8,   0 May 29 21:44 tty00

This, by default, should be  uucp.dialer, permissions crw-rw---,
when "at rest".  When a getty is running, it should be as shown here.

> When logged in it is set to
> crw---  1 maurice  tty8,   0 May 29 22:00 tty00
> Not sure if this is what it should be, but it doesn't look strange to
> me.
> 
> BTW: not sure if it is related, but when I login as normal user, the
> following warning is shown on the terminal:
> ksh: No controlling tty (open /dev/tty: Device busy)
> ksh: warning: won't have full job control
> When I login as root, I don't get this warning.

Ick.  I have my suspicions, but won't voice them since they are
superstitious.  They involve a brief trip to single-user mode and
running  cd /dev; sh MAKEDEV all.

> Any ideas what's going wrong?

Yeah, you're using a serial terminal on a PeeCee. (sarcasm).

You are in a maze of twisty little passages, all alike. The
lamp grows dimmer. (Zork, a metaphor for debugging RS-232).

Install a terminal emulator on the box, like kermit or something
like minicom, from ports if the sometimes goofy behavior of tip/cu
annoys you (like killing its parent xterm when you give it ~.).
Hook up the terminal.  See what you can do.  Try things (settings).
Terminals are a PITA, as bad as serial printers.  See if the 420
has a VT-220 emulation mode, if so try it.  It's hard to debug them
"over the phone" (by email) like this, one needs to poke and try.
A RS232 line analyzer is real handy.  There used to be various
utilities for MS-DOS that would display line status of the com ports
on the screen, much like the blinkenlights on a modem.  Don't know
it they exist for Unix.  Could kermit have such a feature?  One has
to delve into the kernel to see these things, a forbidden zone in
Unix, unless some happy ioctl to pccom exists.

Helpful man pages: tty, tip, remote, cu, getty, gettytab, pccom

With the getty killed, try catting a "large" text file to 
/dev/tty00 (as root), look for garbage on the terminal, a sign
of flow control being wrong.  Try this with the terminal set
for "smooth scrolling".

A debugging test:  use the same cable (if you can) and connect
the com ports of two OpenBSD boxes.  Start the getty on one, and
use tip/cu/minicom/kermit on the other.  Everything should work
fine.  If it doesn't, the cable sucks in some way.  If it doesn't
work, force XON/XOFF on both boxes.  How you do this for getty is
a good question, settings in gettytab is the answer. 

Dave "I already have a headache, and it's not my problem!"