Re: Serial console setup

[Alex D]

On Dec 23, 2016, at 3:41 PM, Julian H. Stacey 
> 
> BTW Later Bill Jollitz back at UCB was author of BSD386 free software
> & articles published in a USA mag. (possibly Byte?) later translated
> in a German mag. (possibly CT ?). There was later a commercial
> offshoot. Somewhere after 2nd patchkit (42 or so?), as feeding
> patches back to Bill didnt work, it was branched to NetBSD or
> FreeBSD. 30 Year old memories, but I'm not sure wikipedia has it
> all & correct, so if you want to correct me, original sources only 

It was published in Dr. Dobb's Journal. IIRC the official name for the release 
was 386BSD. I remember installing on a PC in our lab back at UofT. You had to 
have just the right hardware since it didn't' have a lot of device drivers... 
Lots of people did patches, but there was only one official patch level ... 
Patch level 0.1 ?!? NetBSD kind of forked from that. I remember some of the 
original crew - Chris, Theo and was it Alistair? That was all back in the days 
of newsgroups. I was getting comp.os.* via a UUCP feed from utzoo. Ah... The 
good old times... 

Cheers
alex

Re: Serial console setup

[Thor Lancelot Simon]

On Thu, Dec 22, 2016 at 08:36:47PM -0500, Greg Troxel wrote:
> 
> Note that there are two separate issues with modem control.  One is
> rts/cts.  Probably that is not your problem if text is being output.
> The other is that traditionally, the open from getty on the device did
> not succeed until the modem asserted CD (carrier detect).  Your terminal

If the issue really does have anything to do with carrier detect, it
can be overridden by adding the "softcar" keyword to the line in /etc/ttys.

Thor

Re: Serial console setup

[Michael van Elst]

On Fri, Dec 23, 2016 at 10:46:19AM -0500, Greg Troxel wrote:
> 
> Are you saying that the console device itself will refrain from output
> if either DSR or CD is not asserted?   I can see the point of DSR but
> requiring CD for a console seems non-helpful.

The serial port is meant to control a modem. I've seen several
systems where you could dial-in to the console and it was essential
that the console would wait for CD :)

Saying that, I doubt that a regular serial port of a PC-type machine
requires it, but for low-level console it's still under BIOS control.

The other issue is of course automatic RTS/CTS "flow control", and again,
that's something the BIOS can have configured and is ignored by the
low-level code (so, it's not cleared).


Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Serial console setup

[Julian H. Stacey]

> whatever reason. I haven't seen it on the newer VMAX chassis, but the 
> older Symmetrix "DMX" line used modems quite a bit and people still use 

It seems there's a dual usage of word Symmetrix, Maybe yours is EMC
https://en.wikipedia.org/wiki/EMC_Symmetrix#See_also

Symmetrix for me was an OS that ran in 1987 on a Symmetric 375 I
bought with UCB BSD 4.2 on NSC 16032 11MHz CPU, designed by
Bill Jollitz President of Symmetric Computer Systems Inc.
http://berklix/com/~jhs/symmetric/
Maybe after SCS went belly up, the name Symmetrix came up for grabs ?

Theres also batteries use the name

http://www.neptco.com/website/neptco.nsf/attachments/Symmetrix/$file/Symmetrix.pdf

BTW Later Bill Jollitz back at UCB was author of BSD386 free software
& articles published in a USA mag. (possibly Byte?) later translated
in a German mag. (possibly CT ?). There was later a commercial
offshoot. Somewhere after 2nd patchkit (42 or so?), as feeding
patches back to Bill didnt work, it was branched to NetBSD or
FreeBSD. 30 Year old memories, but I'm not sure wikipedia has it
all & correct, so if you want to correct me, original sources only please.

See Also
https://en.wikipedia.org/wiki/386BSD
https://en.wikipedia.org/wiki/BSD/OS

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#stolen_votes

Re: Serial console setup

[Swift Griggs]

On Fri, 23 Dec 2016, Greg Troxel wrote:

You are not really wrong in theory.


Heh, whew.

There, getty waiting for open to succeed until CD was asserted made 
sense, especially when the modem/line was shared with outgoing UUCP.


Oh, I get what you are saying. Even back in the day I rarely put the 
console on a modem. Rather, as in my case, we'd just setup a "secure" 
getty on the modem (usually with mgetty, if possible since it tended to 
handle modems quite well). The only time I'd stick a modem on the console 
was when I had to ship machines to IT deserts in BFE and I had tested the 
snot outta the rig and had scripts in place to periodically poke-or-reset 
the modem, as needed.


I also wouldn't accept anything less than a top-of-the-line US Robotics 
Courier because rarely did other vendors meet their level of quality and 
speed. I had Zoom and Atmel modems that could never be relied upon if they 
were left to sit for too long with no calls/reset. I'd have never trusted 
those on a must-be-available-or-I'm-screwed-800-miles-away-console port.



A modem console would be beyond bizarre these days.


Heh, very true, but as strange as it is, I've seen it now and again even 
to this day. The main place is on EMC storage arrays where they take 
incoming calls from support to do things like system checks and firmware 
updates. They tend to get a lot less hassle from security folks for 
whatever reason. I haven't seen it on the newer VMAX chassis, but the 
older Symmetrix "DMX" line used modems quite a bit and people still use 
them. There is an outfit on the East coast that still maintains them via 
dial-in, too. Of course, it's not exactly the same thing because I think 
those machines they are either DOS or Windows machines running some kind 
or remote access package (ie.. not gettys). I've also run into 
refrigeration controllers and digital signage systems that also still run 
on modems, but again these are embedded devices, not Unix boxen.


My point was really that if the cables are not wired up right and DCD 
ends up not asserted (there are a lot of wrong serial cables out there), 
then it seems better to just have the console work, rather than not 
work.


I get it now, and I get why you said it and it makes good sense. Ie.. In 
this case, folks can debate which pins to set high or not, but "working" 
is considerably more comfortable than "broken" no matter what "standard" 
is getting violated or who thinks that's not the ideal wiring scheme. 
Right on. :-)


Thanks for explaining.

-Swift

Re: Serial console setup

[Greg Troxel]

Swift Griggs  writes:

> On Fri, 23 Dec 2016, Greg Troxel wrote:
>> Are you saying that the console device itself will refrain from
>> output if either DSR or CD is not asserted?  I can see the point of
>> DSR but requiring CD for a console seems non-helpful.
>
> Hmm, out of ignorance, ('cause I wouldn't gainsay you, Greg!) why?
> Carrier detect is pretty modem-ish, but my simple understanding is
> that when using a null modem, you want to connect DCD to DTR and the
> same for DSR. I've even built cables this way and they worked. It's
> all just non-magical 12V low/high.  That way you've got a "high"
> signal telling you "Yeah, it's cool to talk. We're connected." For a
> modem, that has the additional meaning "You've got a carrier signal"
> rather than just "The cable got plugged in.".
>
> Straigten me out, guys. Am I wrong?

You are not really wrong in theory.

But, when you connect two DTEs with a null modem, there really is no
carrier detect.  And putting a console on an actual modem was odd way
back when (normal would be a DECwriter II on a DL11, and a DZ11 with 8
ports wired to a bunch of modems, on a PDP-11 in 1980 :-).  There, getty
waiting for open to succeed until CD was asserted made sense, especially
when the modem/line was shared with outgoing UUCP.

A modem console would be beyond bizarre these days.

My point was really that if the cables are not wired up right and DCD
ends up not asserted (there are a lot of wrong serial cables out there),
then it seems better to just have the console work, rather than not
work.


signature.asc
Description: PGP signature

Re: Serial console setup

[Swift Griggs]

On Fri, 23 Dec 2016, Greg Troxel wrote:
Are you saying that the console device itself will refrain from output 
if either DSR or CD is not asserted?  I can see the point of DSR but 
requiring CD for a console seems non-helpful.


Hmm, out of ignorance, ('cause I wouldn't gainsay you, Greg!) why? Carrier 
detect is pretty modem-ish, but my simple understanding is that when using 
a null modem, you want to connect DCD to DTR and the same for DSR. I've 
even built cables this way and they worked. It's all just non-magical 12V 
low/high.  That way you've got a "high" signal telling you "Yeah, it's 
cool to talk. We're connected." For a modem, that has the additional 
meaning "You've got a carrier signal" rather than just "The cable got 
plugged in.".


Straigten me out, guys. Am I wrong?

-Swift

Re: Serial console setup

[Greg Troxel]

mlel...@serpens.de (Michael van Elst) writes:

>>I always use crossover cables that ensure CD is asserted by wiring
>>both DSR and CD to the DTR pin of the other end, but if yours doesn't,
>>I would have thought the "local" keyword in /etc/ttys would take care
>>of that.  Or maybe you need to use "softcar" instead?
>
> local or softcar is fine for getty, but it doesn't influence the
> low level console. So depending on hardware you may require the
> proper cable.

Are you saying that the console device itself will refrain from output
if either DSR or CD is not asserted?   I can see the point of DSR but
requiring CD for a console seems non-helpful.

(I haven't really tried to setup a serial console on other than Soekris
for ages; I have one set up on a sparc, but haven't actually plugged it
in for years because I haven't need to rescue the box.)


signature.asc
Description: PGP signature

Re: Serial console setup

[Michael van Elst]

g...@gson.org (Andreas Gustafsson) writes:

>j...@sdf.org wrote:
>> Also, I was looking through the mlist archives and saw mention that
>> /dev/console was suppose to be replaced by /dev/constty ?  Maybe that's
>> the issue?

>I don't think so, since the stock /etc/ttys has

>console "/usr/libexec/getty Pc" vt100   on secure
>constty "/usr/libexec/getty Pc" vt100   off secure

console gets redirected when you run X (in particular xconsole).
Running getty there isn't very helpful.

In that case you can run getty on ttyE0 (for machines with wscons)
or constty (for machines with serial console).



>I always use crossover cables that ensure CD is asserted by wiring
>both DSR and CD to the DTR pin of the other end, but if yours doesn't,
>I would have thought the "local" keyword in /etc/ttys would take care
>of that.  Or maybe you need to use "softcar" instead?

local or softcar is fine for getty, but it doesn't influence the
low level console. So depending on hardware you may require the
proper cable.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Serial console setup

[Andreas Gustafsson]

j...@sdf.org wrote:
> Also, I was looking through the mlist archives and saw mention that
> /dev/console was suppose to be replaced by /dev/constty ?  Maybe that's
> the issue?

I don't think so, since the stock /etc/ttys has

console "/usr/libexec/getty Pc" vt100   on secure
constty "/usr/libexec/getty Pc" vt100   off secure

and I have made no change to that on my machines.  I have made no
changes to boot.cfg any other configuration file, either, but I do
have the boot block configured to use a serial console (as in
installboot -e -o console=com0).

I always use crossover cables that ensure CD is asserted by wiring
both DSR and CD to the DTR pin of the other end, but if yours doesn't,
I would have thought the "local" keyword in /etc/ttys would take care
of that.  Or maybe you need to use "softcar" instead?
-- 
Andreas Gustafsson, g...@gson.org

Re: Serial console setup

[jgw]

Greg Troxel  wrote:
>
> j...@sdf.org writes:
> ..
> > #/var/log/messages
> > ..
> > Dec 20 .. /netbsd: com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working 
> > fifo
> > Dec 20 .. /netbsd: com0: console
>
> I guess that second line shows things are ok
>
> > #/boot.cfg
> > ..
> > menu=Boot Wyse 60:consdev auto;rndseed /var/db/entropy-file;boot netbsd
>
> I am surpriseed at consdev auto, vs "consdev com0".  Try explicitly
> asking the bootloader to set com0 as the console.

I did try "com0" too; no difference.


> Did you program the boot blocks themselves to use the serial console?
> Can you hit space and drop into the prompt, stopping autoboot?

I did not; I was under the impression that that wasn't a hard requirement
anymore.


> > #/etc/ttys
> > ..
> > console "/usr/libexec/getty std.9600"   vt100   on rtscts secure
> > constty "/usr/libexec/getty Pc" vt100   off secure
>
> Note that there are two separate issues with modem control.  One is
> rts/cts.  Probably that is not your problem if text is being output.
> The other is that traditionally, the open from getty on the device did
> not succeed until the modem asserted CD (carrier detect).  Your terminal
> is acting like it has a null modem cable (since it is actually DTE, but
> has a "modem connector" that makes it act like DCE).  (I was surprised at
> first when you said straight-through cable, until you said modem port.
> I am used to terminals that are DTE without modem ports, like a real
> VT100.)

It must have been getting into the wee hours and my memory of what I tried
failed me; I _was_ using a null modem cable connected to the MODEM port
which is as you say a DTE port.  I also tried the AUX port which is DCE.


> So I would definitely recommend "local" in ttys until you get things
> working.

I tried adding local; no difference.


> > # % sudo stty -e -f /dev/console
> > speed 9600 baud; 25 rows; 80 columns; queue = 1024; line = termios;
> > lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
> > -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
> > -nokerninfo -extproc
> > iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk
> > -brkint -inpck -ignpar -parmrk
> > oflags: -opost onlcr -ocrnl -oxtabs -onocr -onlret
> > cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb crtscts -mdmbuf
> > -cdtrcts
> > discard dsusp   eof eol eol2erase   intrkilllnext
> > ^O  ^Y  ^D^?  ^C  ^U  ^V
> > min quitreprint start   status  stopsusptimewerase
> > 1   ^\  ^R  ^Q  ^T  ^S  ^Z  0   ^W
>
> Probably you should look at tty00 or dty00 (dty00 ignores CD, I think)
> instead of console.  console is a logical device for output and perhaps
> BREAK-for-gdb, and I would configure getty on the actual serial port.
> Or at least I would try that.

A search through the mlist archives pulled up a reference to /dev/constty
being the actual console these days; have not tried to reference that yet.


> For what it's worth I have a Soekris net5501 (pc, no vga hw, serial
> console) and I have the boot blocks set to use com0
>
>   # installboot -v -e /dev/rwd0a
>   File system: /dev/rwd0a
>   Boot options:timeout 5, flags 0, speed 9600, ioaddr 0, console com0
>
> and ttys:
>
>   console "/usr/libexec/getty Pc" vt100   on secure
>
> This works with kermit from a mac with a PL2303 USB/serial dongle.
> (Someday I will have time to hook up my VT52!)

I'm thinking the boot block _have_ to be set as you've done.  I'll give
that a try.  Should I be able to use a straight serial cable on the AUX
Wyse (DCE) port?

Jeff

Re: Serial console setup

[Greg Troxel]

j...@sdf.org writes:

> #/var/log/messages
> ..
> Dec 20 .. /netbsd: com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
> Dec 20 .. /netbsd: com0: console

I guess that second line shows things are ok

> #/boot.cfg
> ..
> menu=Boot Wyse 60:consdev auto;rndseed /var/db/entropy-file;boot netbsd

I am surpriseed at consdev auto, vs "consdev com0".  Try explicitly
asking the bootloader to set com0 as the console.

Did you program the boot blocks themselves to use the serial console?
Can you hit space and drop into the prompt, stopping autoboot?

> #/etc/ttys
> ..
> console   "/usr/libexec/getty std.9600"   vt100   on rtscts secure
> constty   "/usr/libexec/getty Pc" vt100   off secure

Note that there are two separate issues with modem control.  One is
rts/cts.  Probably that is not your problem if text is being output.
The other is that traditionally, the open from getty on the device did
not succeed until the modem asserted CD (carrier detect).  Your terminal
is acting like it has a null modem cable (since it is actually DTE, but
has a "modem connector" that makes it act like DCE).  (I was surprised at
first when you said straight-through cable, until you said modem port.
I am used to terminals that are DTE without modem ports, like a real
VT100.)

So I would definitely recommend "local" in ttys until you get things
working.

> # % sudo stty -e -f /dev/console
> speed 9600 baud; 25 rows; 80 columns; queue = 1024; line = termios;
> lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
> -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
> -nokerninfo -extproc
> iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk
> -brkint -inpck -ignpar -parmrk
> oflags: -opost onlcr -ocrnl -oxtabs -onocr -onlret
> cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb crtscts -mdmbuf
> -cdtrcts
> discard dsusp   eof eol eol2erase   intrkilllnext
> ^O  ^Y  ^D^?  ^C  ^U  ^V
> min quitreprint start   status  stopsusptimewerase
> 1   ^\  ^R  ^Q  ^T  ^S  ^Z  0   ^W

Probably you should look at tty00 or dty00 (dty00 ignores CD, I think)
instead of console.  console is a logical device for output and perhaps
BREAK-for-gdb, and I would configure getty on the actual serial port.
Or at least I would try that.

For what it's worth I have a Soekris net5501 (pc, no vga hw, serial
console) and I have the boot blocks set to use com0

  # installboot -v -e /dev/rwd0a
  File system: /dev/rwd0a
  Boot options:timeout 5, flags 0, speed 9600, ioaddr 0, console com0

and ttys:

  console "/usr/libexec/getty Pc" vt100   on secure

This works with kermit from a mac with a PL2303 USB/serial dongle.
(Someday I will have time to hook up my VT52!)


signature.asc
Description: PGP signature

Re: Serial console setup

[Swift Griggs]

On Thu, 22 Dec 2016, j...@sdf.org wrote:
I'm wanting to connect an actual serial terminal (Wyse 60; VT100 mode) 
to a small i386 PC running NetBSD 7.99.25 (snapshot w/ GENERIC kernel).


I used to have a Wyse 60, as well. I think mine was the "paper white" 
model. I used it for years as a terminal to watch my filtered log output 
from about 200 servers at once. I got it for $5 at a used gear auction.


The cable is a straight serial, DB9 (PC COM port) to DB9-DB25 (Wyse 
MODEM port).


Hopefully, you specifically remember using that port on your working SPARC 
rig and you've triple checked your settings on the terminal itself are 
matching.


I added a 'consdev auto' entry to /boot.cfg (see below) which seems to 
get the serial port address right and I'm able to get the dmesg stuff to 
display during bootup but no interaction via the keyboard.


Okay, I could be totally wrong here, but my understanding is that you flat 
out can *NOT* interact with the kernel while it's booting. Ie.. while you 
are seeing "green" text (ie.. the dmesg ring buffer stuff before any 
scripts run).


 I'm also not sure you'll be able to do things like ctrl-c out of startup 
scripts. Linux and other OS's already prevent that from the console 
(*sigh*), but it's nice that NetBSD doesn't. However, I don't remember 
being able to do that unless I'm on a "real" keyboard and watching the 
BIOS (VGA) console. However, I'm not sure exactly why, because I also 
specifically remember doing some netbsd kernel debugging (ie.. gathering 
backtraces and what-not) from a serial console that totally worked. 
However, I believe it was because, on that particular system, it didn't 
have a framebuffer and the BIOS console *was* the serial port.


 I tried various combinations of [Full|Half]Duplex and RCV Handshake 
[none|XON/XOFF|DTR|both] ; none enabled 2-way communication.


I always had the best luck with my Wyse using hardware flow control (DTR). 
IIRC, they will go up to 38,400 pretty reliably. You definitely want to 
keep it in full duplex, too.



Current settings are attached. Is there something more I need to do?


Not to be an ass, but you do know you've got to fire up a getty for the 
terminal in /etc/inittab once the system is booted, right? The console 
stuff you've done basically only enables the kernel displaying it's ring 
buffer output and what-not. To login et al, you'll need a getty.


-Swift

Re: Serial console setup

[jgw]

Andreas Gustafsson  wrote:

> j...@sdf.org wrote:
> > I'm wanting to connect an actual serial terminal (Wyse 60; VT100 mode) to
> > a small i386 PC running NetBSD 7.99.25 (snapshot w/ GENERIC kernel).  The
> > cable is a straight serial, DB9 (PC COM port) to DB9-DB25 (Wyse MODEM
> > port).  I added a 'consdev auto' entry to /boot.cfg (see below) which
> > seems to get the serial port address right and I'm able to get the dmesg
> > stuff to display during bootup but no interaction via the keyboard.  I
> > tried various combinations of [Full|Half]Duplex and RCV Handshake
> > [none|XON/XOFF|DTR|both] ; none enabled 2-way communication.
> > 
> > Current settings are attached. Is there something more I need to do?
>
> Try adding the "local" keyword to the line for your port in /etc/ttys.

Unfortunately that didn't seem to make any difference. :/

It's really a mystery; I've used this Wyse on Sparcs running NetBSD w/o
any real fiddling, though I think those were designed to be serial console
friendly, automagically switching if one was connected to the serial port.

Also, I was looking through the mlist archives and saw mention that
/dev/console was suppose to be replaced by /dev/constty ?  Maybe that's
the issue?

Jeff

Serial console setup

[jgw]

Hi,
I'm wanting to connect an actual serial terminal (Wyse 60; VT100 mode) to
a small i386 PC running NetBSD 7.99.25 (snapshot w/ GENERIC kernel).  The
cable is a straight serial, DB9 (PC COM port) to DB9-DB25 (Wyse MODEM
port).  I added a 'consdev auto' entry to /boot.cfg (see below) which
seems to get the serial port address right and I'm able to get the dmesg
stuff to display during bootup but no interaction via the keyboard.  I
tried various combinations of [Full|Half]Duplex and RCV Handshake
[none|XON/XOFF|DTR|both] ; none enabled 2-way communication.

Current settings are attached. Is there something more I need to do?

Jeff

--
Some info from the current setup:

#/var/log/messages
..
Dec 20 .. /netbsd: com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
Dec 20 .. /netbsd: com0: console

#/boot.cfg
..
menu=Boot Wyse 60:consdev auto;rndseed /var/db/entropy-file;boot netbsd

#/etc/ttys
..
console "/usr/libexec/getty std.9600"   vt100   on rtscts secure
constty "/usr/libexec/getty Pc" vt100   off secure

# % sudo stty -e -f /dev/console
speed 9600 baud; 25 rows; 80 columns; queue = 1024; line = termios;
lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
-echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
-nokerninfo -extproc
iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk
-brkint -inpck -ignpar -parmrk
oflags: -opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb crtscts -mdmbuf
-cdtrcts
discard dsusp   eof eol eol2erase   intrkilllnext
^O  ^Y  ^D^?  ^C  ^U  ^V
min quitreprint start   status  stopsusptimewerase
1   ^\  ^R  ^Q  ^T  ^S  ^Z  0   ^W