Dropping DTR in OSR5
Frank da Cruz
In getting C-Kermit 8.0 ready for release:
http://www.columbia.edu/kermit/ck80.html
I was testing it on SCO OSR5.0.5 and discovered that the DIAL command
didn't work:
set modem type usrobotics
set line /dev/tty1A
set speed 38400
dial 7654321
The DIAL command turns off DTR and RTS and they don't come on again.
This can be worked around by giving Kermit either of the following commands:
set dial hangup off
set modem hangup-command modem-command
Each of these prevents Kermit from trying to drop DTR for half a second
prior to dialing.
But the real problem is that when Kermit *does* try to drop DTR briefly,
it never comes back on. So I need to ask: What is the way to turn off
DTR and then turn it back on in OSR5? Currently I am using the POSIX
way:
cfgetospeed() and cfgetispeed() to get the speeds.
cfsetospeed() and cfsetispeed() to set the speed to 0.
tcsetattr() to make the speed changes take effect.
(pause)
cfsetospeed() and cfsetispeed() to restore the original speeds.
tcsetattr() to make the speed changes take effect.
The same code works fine on Linux, FreeBSD, and other platforms that use
POSIX APIs. It appears to work fine in OSR5 too: the steps before the
pause actually do work. But the steps after the pause, although they
return no error indication and do not set errno, do not in fact make DTR
and RTS come back on (as shown by the modem lights and the failure of the
modem to respond to further commands).
Speaking of modem signals, how are we supposed to read them? The TIOCMGET
ioctl() fails with error 22 ("invalid argument").
Thanks.
- Frank
John DuBois
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>But the real problem is that when Kermit *does* try to drop DTR briefly,
>it never comes back on. So I need to ask: What is the way to turn off
>DTR and then turn it back on in OSR5? Currently I am using the POSIX
>way:
>
> cfgetospeed() and cfgetispeed() to get the speeds.
> cfsetospeed() and cfsetispeed() to set the speed to 0.
> tcsetattr() to make the speed changes take effect.
> (pause)
> cfsetospeed() and cfsetispeed() to restore the original speeds.
> tcsetattr() to make the speed changes take effect.
>
>The same code works fine on Linux, FreeBSD, and other platforms that use
>POSIX APIs. It appears to work fine in OSR5 too: the steps before the
>pause actually do work. But the steps after the pause, although they
>return no error indication and do not set errno, do not in fact make DTR
>and RTS come back on (as shown by the modem lights and the failure of the
>modem to respond to further commands).
Some problems in this area were fixed in 5.0.6a. Please test on that release
and see if you still encounter this problem.
>Speaking of modem signals, how are we supposed to read them? The TIOCMGET
>ioctl() fails with error 22 ("invalid argument").
This is how I know you aren't using 5.0.6a :) TIOCMGET/TIOCMSET/etc. were
first implemented in the sio driver in that release. In earlier releases,
support for these ioctls was present only in certain 3rd party serial drivers.
John
--
John DuBois spc...@armory.com. KC6QKZ/AE http://www.armory.com./~spcecdt/
Frank da Cruz
John DuBois <spc...@deeptht.armory.com> wrote:
: In article <9s40rp$fdh$1...@newsmaster.cc.columbia.edu>,
: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
: >But the real problem is that when Kermit *does* try to drop DTR briefly,
: >
: > cfgetospeed() and cfgetispeed() to get the speeds.
: > cfsetospeed() and cfsetispeed() to set the speed to 0.
: > tcsetattr() to make the speed changes take effect.
: > (pause)
: > cfsetospeed() and cfsetispeed() to restore the original speeds.
: > tcsetattr() to make the speed changes take effect.
: Some problems in this area were fixed in 5.0.6a. Please test on that release
: and see if you still encounter this problem.
Unfortunately I don't have access to a 5.0.6a system that I can dial out
from.
: >Speaking of modem signals, how are we supposed to read them? The TIOCMGET
: >ioctl() fails with error 22 ("invalid argument").
:
: This is how I know you aren't using 5.0.6a :)
:
Besides that I said I was using 5.0.5? :-) (More or less the same behavior
occurs on 5.0.2 -- the difference being that in 5.0.5 DTR and RTS both go
down and stay down; in 5.0.2 DTR and RTS both go down, DTR comes back up
but RTS does not, so the modem still won't listen to commands.)
: TIOCMGET/TIOCMSET/etc. were first implemented in the sio driver in that
: release. In earlier releases, support for these ioctls was present only in
: certain 3rd party serial drivers.
:
So is it true to say that in OSR5.0.5 and earler just plain can't hang up
a modem by any means short of closing the device and reopening it?
- Frank
Bela Lubkin
> In article <9s40rp$fdh$1...@newsmaster.cc.columbia.edu>,
> Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
> >But the real problem is that when Kermit *does* try to drop DTR briefly,
> >it never comes back on. So I need to ask: What is the way to turn off
> >DTR and then turn it back on in OSR5? Currently I am using the POSIX
> >way:
> >
> > cfgetospeed() and cfgetispeed() to get the speeds.
> > cfsetospeed() and cfsetispeed() to set the speed to 0.
> > tcsetattr() to make the speed changes take effect.
> > (pause)
> > cfsetospeed() and cfsetispeed() to restore the original speeds.
> > tcsetattr() to make the speed changes take effect.
> >
> >The same code works fine on Linux, FreeBSD, and other platforms that use
> >POSIX APIs. It appears to work fine in OSR5 too: the steps before the
> >pause actually do work. But the steps after the pause, although they
> >return no error indication and do not set errno, do not in fact make DTR
> >and RTS come back on (as shown by the modem lights and the failure of the
> >modem to respond to further commands).
>
> Some problems in this area were fixed in 5.0.6a. Please test on that release
> and see if you still encounter this problem.
While this is true, Frank likes to support every OS ever made. I
believe he still builds binaries for SCO Xenix. A solution which
requires users to have an OS less than a year old won't satisfy him...
The OpenServer "sio" driver doesn't implement ispeed and ospeed as
separate entities. The functions exist and the structures have all the
necessary members, but it doesn't pay attention to the input rate, only
the output rate. At least, that's how it's _intended_ to work. I
vaguely remember that you can get into trouble -- confuse the driver --
by trying to change both. This might have been one of the things fixed
in rs506a. But I think the problem can be avoided on all releases, by
only programming the output speed.
So, suppose you test with only changing ospeed, see whether that makes a
difference?
This also isn't a general solution. There are third party drivers that
slot into the same ioctls, but _do_ correctly support independent i/o
speeds. Does Kermit have any system-specific hint settings? Something
like an OpenServer-specific "set ignore-ospeed", turned on by default?
"On" is the correct default since "sio" is the most common serial driver
on OpenServer, and split-speed usage is rather uncommon.
And, if I'm wrong, you might try an even kludgier workaround (which also
might not work, but is definitely worth trying): after having performed
all the POSIXly correct incantations, i.e. after the 2nd tcsetattr() in
your pseudo-code above, force an extra open of the port:
...
tcsetattr()
if ((kludge_fd = open(the_port, O_RDONLY | O_NONBLOCK | O_NOCTTY)) >= 0)
close(kludge_fd);
I'm pretty sure this will cause "sio" to get its house in order and
raise DTR (and the close shouldn't lower it, since the other open still
exists). For debugging purposes you might need to put in a pause before
the close() to observe that DTR actually goes on -- I don't fully trust
my assertion that the close() won't lower it.
One last thing. There's a comment in the driver that implies that after
cycling the baud rate through 0, DTR might not come back up immediately;
might only come up when you output a character. I'm pretty sure this is
fixed in rs506a, but for older releases, see whether outputting a NUL
after the 2nd tcsetattr() causes DTR to wake up.
>Bela<
Frank da Cruz
Bela Lubkin <be...@caldera.com> wrote:
: John DuBois wrote:
: > ...
: > Some problems in this area were fixed in 5.0.6a. Please test on that
: > release and see if you still encounter this problem.
:
: While this is true, Frank likes to support every OS ever made. I
: believe he still builds binaries for SCO Xenix. A solution which
: requires users to have an OS less than a year old won't satisfy him...
Strange but absolutely true. People still run old -- even ancient --
Unix OS's, including SCO Xenix. Doctors' offices are a good place to
look for computing antiques. I know a doctor who runs his practice from
an AT&T 3B2. The billing package only runs there, the vendor disappeared
decades ago...
: The OpenServer "sio" driver doesn't implement ispeed and ospeed as
: separate entities. The functions exist and the structures have all the
: necessary members, but it doesn't pay attention to the input rate, only
: the output rate. At least, that's how it's _intended_ to work.
:
Aha, the truth comes out... Strict POSIX on the outside, not so strict
on the inside :-)
Actually a pet peeve of mine is how latter-day SCO header files (and
most other vendors) are full of:
#if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE)
to keep you from getting at anything useful -- hardware flow control, for
example. In many cases also high serial speeds. But I digress...
: I vaguely remember that you can get into trouble -- confuse the driver --
: by trying to change both. This might have been one of the things fixed in
: rs506a. But I think the problem can be avoided on all releases, by only
: programming the output speed. So, suppose you test with only changing
: ospeed, see whether that makes a difference?
:
I just tried this on 5.0.2 -- no difference. DTR and RTS go down,
but only DTR come back up.
: This also isn't a general solution. There are third party drivers that
: slot into the same ioctls, but _do_ correctly support independent i/o
: speeds. Does Kermit have any system-specific hint settings? Something
: like an OpenServer-specific "set ignore-ospeed", turned on by default?
: "On" is the correct default since "sio" is the most common serial driver
: on OpenServer, and split-speed usage is rather uncommon.
:
The third-party drivers is a land I don't have a passport for. Device
names, lockfile conventions, who knows what else. I have reams of
correspondence on this stuff, and the conclusion is always "don't touch
it". I figure if Digi or Stallion or somebody wants Kermit to support
their stuff, they'll contact me about it.
: And, if I'm wrong, you might try an even kludgier workaround (which also
: might not work, but is definitely worth trying): after having performed
: all the POSIXly correct incantations, i.e. after the 2nd tcsetattr() in
: your pseudo-code above, force an extra open of the port:
:
: ...
: tcsetattr()
: if ((kludge_fd = open(the_port, O_RDONLY | O_NONBLOCK | O_NOCTTY)) >= 0)
: close(kludge_fd);
:
: I'm pretty sure this will cause "sio" to get its house in order and
: raise DTR (and the close shouldn't lower it, since the other open still
: exists). For debugging purposes you might need to put in a pause before
: the close() to observe that DTR actually goes on -- I don't fully trust
: my assertion that the close() won't lower it.
:
In fact DTR comes back on, but RTS stays down, just as without the kludge.
The kludge does make a difference in 5.0.5, however: it makes it act like
5.0.2 (without the kludge in 5.0.5, both DTR and RTS stayed down).
: One last thing. There's a comment in the driver that implies that after
: cycling the baud rate through 0, DTR might not come back up immediately;
: might only come up when you output a character. I'm pretty sure this is
: fixed in rs506a, but for older releases, see whether outputting a NUL
: after the 2nd tcsetattr() causes DTR to wake up.
:
In 5.0.2 DTR came up anyway, but RTS does not come back up, even when you
send bytes. Ditto for 5.0.5 with and without all the above tricks.
In short there seems to be no way to do this in OSR5 prior to 5.0.6a. Hard
to believe, right? But not surprising either since I think Kermit must be
the only program that would want to momentarily drop DTR without closing the
device (and of course the problem with closing the device is that you've
lost all the myriad setups you've done on it when you reopen it).
Thanks!
- Frank
Bela Lubkin
> In article <2001110416...@mammoth.ca.caldera.com>,
> Bela Lubkin <be...@caldera.com> wrote:
> : John DuBois wrote:
> : > ...
> : > Some problems in this area were fixed in 5.0.6a. Please test on that
> : > release and see if you still encounter this problem.
> :
> : While this is true, Frank likes to support every OS ever made. I
> : believe he still builds binaries for SCO Xenix. A solution which
> : requires users to have an OS less than a year old won't satisfy him...
> :
> Strange but absolutely true. People still run old -- even ancient --
> Unix OS's, including SCO Xenix. Doctors' offices are a good place to
> look for computing antiques. I know a doctor who runs his practice from
> an AT&T 3B2. The billing package only runs there, the vendor disappeared
> decades ago...
It's a good thing you're doing, providing support for the stragglers.
> : The OpenServer "sio" driver doesn't implement ispeed and ospeed as
> : separate entities. The functions exist and the structures have all the
> : necessary members, but it doesn't pay attention to the input rate, only
> : the output rate. At least, that's how it's _intended_ to work.
> :
> Aha, the truth comes out... Strict POSIX on the outside, not so strict
> on the inside :-)
Yep, just like every piece of software that claims adherence to any sort
of public standard...
> Actually a pet peeve of mine is how latter-day SCO header files (and
> most other vendors) are full of:
>
> #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE)
>
> to keep you from getting at anything useful -- hardware flow control, for
> example. In many cases also high serial speeds. But I digress...
The devsys engineers at SCO (and perhaps today at Caldera) believed that
if you asked for POSIX compliance, you were asking the devsys to act as
a filter to prevent you from doing anything that wasn't specified in the
POSIX standard(s) in question; i.e. you were doing primary development
on this platform and wanted to be kept away from anything that would
make your code non-portable. Most users, of course, think of these
flags as an _enabler_, "please _give_ me access to all the stuff implied
by such-and-such standard". These are radically incompatible semantics.
The OSR5 devsys defaults to an "XPG plus" mode that is intended to give
you everything in all the standards the OS supports, plus whatever local
oddities exist. Most cases where functionality is hidden behind an
ifdef like you show above, are probably bugs. They _should_ say:
#if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) || defined(_XOPEN_SOURCE_EXTENDED)
I looked through the 13 header files that match, and some need to stay
the way they are; and changing any of them would probably break the
build of various already-ported programs. So, probably shouldn't mess
with them.
> : I vaguely remember that you can get into trouble -- confuse the driver --
> : by trying to change both. This might have been one of the things fixed in
> : rs506a. But I think the problem can be avoided on all releases, by only
> : programming the output speed. So, suppose you test with only changing
> : ospeed, see whether that makes a difference?
>
> I just tried this on 5.0.2 -- no difference. DTR and RTS go down,
> but only DTR come back up.
Ok, so much for vague memories.
> : This also isn't a general solution. There are third party drivers that
> : slot into the same ioctls, but _do_ correctly support independent i/o
> : speeds. Does Kermit have any system-specific hint settings? Something
> : like an OpenServer-specific "set ignore-ospeed", turned on by default?
> : "On" is the correct default since "sio" is the most common serial driver
> : on OpenServer, and split-speed usage is rather uncommon.
>
> The third-party drivers is a land I don't have a passport for. Device
> names, lockfile conventions, who knows what else. I have reams of
> correspondence on this stuff, and the conclusion is always "don't touch
> it". I figure if Digi or Stallion or somebody wants Kermit to support
> their stuff, they'll contact me about it.
Hmmm, I would expect Kermit to just work with 3rd party drivers on OSR5.
Device names? Kermit shouldn't care -- if I tell it "let's talk on
/dev/ttyi13A" it should say "ok, boss". Lockfile convention are
something you have to work out between you and other user-level programs
(like the OS's `cu` and `uucico`), not with drivers; and the answers for
OSR5 are well known.
> : And, if I'm wrong, you might try an even kludgier workaround (which also
> : might not work, but is definitely worth trying): after having performed
> : all the POSIXly correct incantations, i.e. after the 2nd tcsetattr() in
> : your pseudo-code above, force an extra open of the port:
> :
> : ...
> : tcsetattr()
> : if ((kludge_fd = open(the_port, O_RDONLY | O_NONBLOCK | O_NOCTTY)) >= 0)
> : close(kludge_fd);
> :
> : I'm pretty sure this will cause "sio" to get its house in order and
> : raise DTR (and the close shouldn't lower it, since the other open still
> : exists). For debugging purposes you might need to put in a pause before
> : the close() to observe that DTR actually goes on -- I don't fully trust
> : my assertion that the close() won't lower it.
>
> In fact DTR comes back on, but RTS stays down, just as without the kludge.
> The kludge does make a difference in 5.0.5, however: it makes it act like
> 5.0.2 (without the kludge in 5.0.5, both DTR and RTS stayed down).
Oh well.
> : One last thing. There's a comment in the driver that implies that after
> : cycling the baud rate through 0, DTR might not come back up immediately;
> : might only come up when you output a character. I'm pretty sure this is
> : fixed in rs506a, but for older releases, see whether outputting a NUL
> : after the 2nd tcsetattr() causes DTR to wake up.
>
> In 5.0.2 DTR came up anyway, but RTS does not come back up, even when you
> send bytes. Ditto for 5.0.5 with and without all the above tricks.
>
> In short there seems to be no way to do this in OSR5 prior to 5.0.6a. Hard
and you only have John's say-so with regard to 506a...
> to believe, right? But not surprising either since I think Kermit must be
> the only program that would want to momentarily drop DTR without closing the
> device (and of course the problem with closing the device is that you've
> lost all the myriad setups you've done on it when you reopen it).
Well, no, people are asking all the time about what ioctls to use to
drop DTR momentarily. Which is why John finally implemented TIOCMGET et
al for 506a; which of course doesn't help you.
One more trick you could do -- but which does more firmly tie you to
"sio". If you're working on tty1a, open and close tty1A. That should
be sufficient to kick RTS, DTR back to sanity. And if you're working on
1A then open/close 1a. None of which is particularly pleasant. I might
also be wrong in that _opening_ might fix RTS & DTR, but closing might
screw them up again, so you would need to open and keep open the "other"
device node. (Then, next time you need to do something to force correct
RTS & DTR, close and reopen that "other" port.)
yecch.
>Bela<
Robert Lipe
>In article <2001110416...@mammoth.ca.caldera.com>,
>Bela Lubkin <be...@caldera.com> wrote:
>
>: The OpenServer "sio" driver doesn't implement ispeed and ospeed as
>: separate entities. The functions exist and the structures have all the
>: necessary members, but it doesn't pay attention to the input rate, only
>: the output rate. At least, that's how it's _intended_ to work.
>:
>Aha, the truth comes out... Strict POSIX on the outside, not so strict
>on the inside :-)
Well, it's more forgivable than you make it sound. The hardware that
sio supports won't do the split bit rate thing so it's quite reasonable
for sio to lock ispeed and ospeed together.
I have in my lap the data sheets for the 8250, 16450, 16550 chips. They
just won't do it. Split bit rates were common in the 60's and 70's but
are very uncommon in the modern world so most new silicon won't support
it, either.
>: One last thing. There's a comment in the driver that implies that after
>: cycling the baud rate through 0, DTR might not come back up immediately;
I've long considered it a spec defect that B0 describes that that DTR
is deasserted but it's never spelled out precisely when it comes back.
>I think Kermit must be the only program that would want to momentarily
>drop DTR without closing the device (and of course the problem with
Rest assureed you're not the only one. Unfortunately, it tends to be a
rather disappointed crowd...
Frank da Cruz
Bela Lubkin <be...@caldera.com> wrote:
: ...
: The devsys engineers at SCO (and perhaps today at Caldera) believed that
: if you asked for POSIX compliance, you were asking the devsys to act as
: a filter to prevent you from doing anything that wasn't specified in the
:
Right. It's not a criticism of SCO; it's a criticism of POSIX. Most of
the things that communication software needs to do are forbidden by POSIX.
: Hmmm, I would expect Kermit to just work with 3rd party drivers on OSR5.
: Device names? Kermit shouldn't care -- if I tell it "let's talk on
: /dev/ttyi13A" it should say "ok, boss".
:
I don't have my notes handy at the moment, but as I recall the problem
comes when a driver supports hundreds of serial ports, thus stressing the
SCO port-naming conventions and lockfile-name-devising algorithm.
: > In fact DTR comes back on, but RTS stays down, just as without the kludge.
: > The kludge does make a difference in 5.0.5, however: it makes it act like
: > 5.0.2 (without the kludge in 5.0.5, both DTR and RTS stayed down).
:
: Oh well.
:
I tried one last trick this morning. It doesn't work either, but I don't
know why. Maybe somebody can explain it. Last night I said:
: > ...(and of course the problem with closing the device is that you've
: > lost all the myriad setups you've done on it when you reopen it).
But after posting that I realized that in the POSIX environment (unlike in
BSD or System V) everything you need to know about the port is in one place:
the attribute struct. So the following should work:
tcgetattr(ttyfd, &ttcur);
close(ttyfd);
(pause)
ttyfd = open(name,O_RDWR|O_NONBLOCK);
tcsetattr(ttyfd,TCSADRAIN,&ttcur);
Right? Well, it does work insofar as it drops DTR and RTS for the desired
interval and they both come on again. However, any write() to the reopened
device gets error 11, "Resource temporarily unavailable".
: > In short there seems to be no way to do this in OSR5 prior to 5.0.6a.
:
: and you only have John's say-so with regard to 506a...
:
At some point I'd like to get somebody who has 5.0.6a and an external modem
to build and test my working copy of C-Kermit 8.0 to see if:
. The TIOCSDTR code gets included in tthang().
. SET MODEM HANGUP-METHOD RS232 really works.
. SHOW COMM displays the modem signals.
. Kermit automatically pops back to its prompt if CD drops during a
terminal session or file transfer.
The working sources are here:
ftp://kermit.columbia.edu/kermit/test/tar/x.tar.gz (also .Z)
(Is the big difference between 5.0.5 and 5.0.6 or between 5.0.6 and 5.0.6a?)
Ditto for Unixware 7 and Open UNIX 8.
: One more trick you could do -- but which does more firmly tie you to
: "sio". If you're working on tty1a, open and close tty1A. That should
: be sufficient to kick RTS, DTR back to sanity. And if you're working on
: 1A then open/close 1a. None of which is particularly pleasant. I might
: also be wrong in that _opening_ might fix RTS & DTR, but closing might
: screw them up again, so you would need to open and keep open the "other"
: device node. (Then, next time you need to do something to force correct
: RTS & DTR, close and reopen that "other" port.)
:
Opening the "other" port after tcsetattr() makes DTR come on but not RTS.
The behavior is the same if I close it or leave it open.
- Frank