modem dtr

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.com>
Subject: Re: Dropping DTR in OSR5
Date: Mon, 5 Nov 2001 00:09:17 GMT
References: <9s40rp$fdh$1@newsmaster.cc.columbia.edu> <3be5c667$0$439$8eec23a@newsreader.tycho.net> 

John DuBois wrote:

> In article <9s40rp$fdh$1@newsmaster.cc.columbia.edu>,
> Frank da Cruz <fdc@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<
 

Take Control of Screen Sharing in Leopard

Take Control of Permissions in Leopard

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.