[ILUG] (en?/dis?)-abling modem-control signals on a (not-open) serial port?

[Brian Foster]

  | Date: Sun, 01 Jul 2007 00:25:09 +0100
  | From: Michael Watterson <watty at eircom.net>
  | 
  | Brian Foster wrote:
  | >[ ...on SUSE 9.1 ] the bash(1) command:
  | >    isserial </dev/ttyS1
  | >  is hanging; strace(1) shows the (bash) open(2) of
  | >  /dev/ttyS1 is hanging.  [ ... ttyS1 is the serial
  | >  modem, which is off-line and NOT open ... ].
  | >
  | >[ ... ] the hang is because the line has _somehow_ been
  | >  configured to require various modem-control signals
  | > (i.e., it's not a simple 3-wire connection).  [ ... ]
  | > the (admittedly unused) non-modem serial port is not
  | > so configured.
  | >
  | >[ ... ]  how does Linux (2.6) configure a serial port
  | >  to use (or to not use?) modem-control signals?  [ ... ]
  | 
  |[... story I found confusing but which suggests to me
  |   Michael wants to do non-blocking non-canonical I/O
  |   on a local (i.e., non-modem) serial connection, but
  |   is unable to use minicom(1).   or something?...]
  | Presumably there is a Linux KDE equivalent to MS Hyperterminal for 
  | serial, that is free and actually does what I want, but I don;t know 
  | what it is.

 not very helpful, but I have (vague!) memories of using
 `minicom' in the past on non-modem serial connections,
 but cannot recall if they were 3-wire or not (and if
 3-wire, whether or not the DCD et al. signals were faked
 in the usual manner).  in any case, you might want to
 take a look at `kermit'?  or, depending on just what the
 issue(s?) is, the ancient cu(1) could possibly be used?

 more technically, it sounds to me what you want on the
 serial side is a `clocal -icanon' setting (with `vmin'
 and `vtime' set appropriately), _maybe_ with the port
 opened non-blocking.  that's fairly standard stuff.

 as such, it is mostly unconnected to my puzzle, except
 for the `clocal' part:  put more concisely, my question
 is how does SUSE 9.1 / Linux 2.6 arrange for ¬clocal to
 be set on the NOT-open ttyS1 modem port, and clocal on
 the (not-used) NOT-open ttyS0 port?

 putting it another way:  it's probable something is
 either setting clocal on ttyS1, or clearing it (¬clocal)
 on ttyS0.  I am puzzled by the WHO:  who is doing this?

 ( the above only(?) makes sense if the (¬)clocal setting
  stays in effect after last close; i.e., even when the
  line is not open.  given clocal's affect on open(2),
  this makes sense. ).

  | Additonally there are three schemes for RS232 hardware handshake wiring, 
  | using one or two or both schemes of HW signalling,. A Modem can use two 
  | of them at same time, a Terminal or inter PC only needs either of those 
  | two, and some serial printers have used a third wiring scheme. Oridinary 
  | modems never use Xon/Xoff SW handshake.

 yep.  and also not relevant, since those are data flow
 control schemes.  data can flow only when the line is
 open.  which it isn't.

 what is (very probably) happening in my case is the
 off-line modem is not asserting DCD (which is correct),
 and hence, since the line is ¬clocal, the open hangs.
 nominally, DCD is asserted once there is a carrier
 (i.e., once the phone call has been answered et al.),
 and unblocks the hanging open.

 what I'm curious about is how the ¬clocal setting is
 being arranged?  the port's NOT-open, so (I'm guessing)
 that mysterious something must have done something to
 arrange for ¬clocal?

cheers!
	-blf-
-- 
▶ ▶  I AM CURRENTLY LOOKING FOR A JOB!  ◀ ◀ | Brian Foster
Experienced (>25 yrs) software engineer:    |        Montpellier, FRANCE
 • Unix, Linux, embedded, design-for-test;  | Stop E$$o (ExxonMobile)!
 • Software/hardware co-design, debugging;  |     http:/www.stopesso.com
 • Kernels, drivers, filesystems, &tc;    Résumé (CV) & contact details:
 • IDL, automated testing, process, &tc.   http://www.blf.utvinternet.ie